DEV Community: Ryan

Testing Activity lifecycle callback methods in Android

Ryan — Sun, 12 Jan 2020 17:27:29 +0000

Suppose that you're testing an Activity class. In this Activity class, the Intent used to start the Activity causes a difference in behavior in the onCreate(), onStart() or onResume() lifecycle callbacks. Therefore, you need to test that the Activity class treats different Intent instances differently. This is straightforward enough, right? Just create a different Intent for a bunch of different variations of the test . . . but how do you do that?

As a simple example that illustrates the true problem in setting up the test and motivates the solution, we're just going to have a Activity that shows a TextView. The requirements for this new Activity are as follows:

If the Intent used to start it DOES NOT have the "text" string extra, then show "Hello World!"
If the Intent used to start it DOES have the "text" string extra, then show whatever is in that extra

So to get started, do the following:

Create a new project via AndroidStudio
Select the Empty Activity option
Open the generated activity_main.xml layout file and add the following attribute to the TextView element: android:id="@+id/hello" (which will allow us to reference it in the test and in the MainActivity
Add the following androidTestImplementation dependency to your app's build.gradle file: androidTestImplementation 'androidx.test:rules:1.1.0'

Now that you have the setup in-place, Create a new class in the androidTest source set:

@RunWith(AndroidJUnit4.class)
public class MainActivityTest {

    @Rule
    public final ActivityTestRule<MainActivity> rule
            = new ActivityTestRule<>(MainActivity.class);

    @Test
    public void shouldShowHelloWorldByDefault() {
        Espresso.onView(ViewMatchers.withId(R.id.hello))
                .check(ViewAssertions.matches(ViewMatchers.withText("Hello World!")));
    }
}

This test is good enough to test the default case. And it passes! And it was pretty easy to write. So far so good!

What about the non-default case? Alright--lets customize the Intent we send into the Activity. In order to do that, we'll create an inline extension of ActivityTestRule that overrides the getActivityIntent() method:

@RunWith(AndroidJUnit4.class)
public class MainActivityTest {

    @Rule
    public final ActivityTestRule<MainActivity> rule
            = new ActivityTestRule<MainActivity>(MainActivity.class) {
        @Override
        protected Intent getActivityIntent() {
            return new Intent(getApplicationContext(), MainActivity.class)
                    .putExtra("text", "Goodbye, Cruel World!");
        }
    };

    @Test
    public void shouldShowHelloWorldByDefault() {
        Espresso.onView(ViewMatchers.withId(R.id.hello))
                .check(ViewAssertions.matches(ViewMatchers.withText("Hello World!")));
    }
}

That was easy enough, and our test still passes, but it really shouldn't. It passes because we haven't actually updated the MainActivity to set the text by the intent. Lets do that:

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        String text = getIntent().getStringExtra("text");
        if (text != null) {
            ((TextView) findViewById(R.id.hello)).setText(text);
        }
    }
}

That should be enough to support the requirements of the MainActivity, but now our test, correctly, fails. Lets just ignore that test for now and write a test that will expect "Goodbye, Cruel World!" to be shown:

@RunWith(AndroidJUnit4.class)
public class MainActivityTest {

    @Rule
    public final ActivityTestRule<MainActivity> rule
            = new ActivityTestRule<MainActivity>(MainActivity.class) {
        @Override
        protected Intent getActivityIntent() {
            return new Intent(getApplicationContext(), MainActivity.class)
                    .putExtra("text", "Goodbye, Cruel World!");
        }
    };

    @Ignore
    @Test
    public void shouldShowHelloWorldByDefault() {
        Espresso.onView(ViewMatchers.withId(R.id.hello))
                .check(ViewAssertions.matches(ViewMatchers.withText("Hello World!")));
    }

    @Test
    public void shouldShowTextFromExtraInIntent() {
        Espresso.onView(ViewMatchers.withId(R.id.hello))
                .check(ViewAssertions.matches(ViewMatchers.withText("Goodbye, Cruel World!")));
    }
}

So we've got a problem testing more than one case in the same test class. Now that the problem has been established, why is it a problem? The answer is that the lifecycle of your JUnit4 test starts AFTER the Activity you're testing has been resumed.

Don't worry--we're going to solve this problem.

A few naive approaches

One could imagine a few different ways to solve this issue. Here are a couple naive ways:

Create a test class for each intent that you want to send to launch the Activity
Delay the launch of the activity you're testing by starting the activity you want to test from an intermediate activity.

Why are these approaches naive?

Creating a new test class for each intent you want to use will work for you only if the number of cases is low. For example, there are three cases that we need to test:

The default case
The non-default case
The non-default case with a different value than in case 2 (to ensure that the source of the string was, indeed the intent extra)

However, as the number of cases proliferate, it could get laborious to maintain all of those test classes.

Delaying the launch of the activity under test by using an intermediary is one way to work around the proliferation of classes and copied code. However, there are two reasons why this solution is not the best:

You have to launch an activity that you don't intend to test in order to test the activity you intend to test. Thus, you need to create this dummy Activity class.
This approach works best with the ActivityTestRule constructor that launches the activity once per test class instead of launching a new activity per test. Doing so opens the door to leaking state between tests.

Some better solutions

The following are two better solutions:

(not recommended) Use the JUnit4 Parameterized test runner and constructor arguments to parameterize your test. See the drawbacks of this approach below.
Write a custom RUNTIME retention annotation that you then read when the ActivityTestRule is applied.

The JUnit4 Parameterized Runner approach

@RunWith(Parameterized.class)
public class MainActivityTest {

    public String extraText;
    public String expectedText;

    public MainActivityTest(String extraText, String expectedText) {
        this.extraText = extraText;
        this.expectedText = expectedText;
    }

    @Rule
    public final ActivityTestRule<MainActivity> rule
            = new ActivityTestRule<MainActivity>(MainActivity.class) {
        @Override
        protected Intent getActivityIntent() {
            return new Intent(getApplicationContext(), MainActivity.class)
                    .putExtra("text", extraText);

        }
    };

    @Parameterized.Parameters
    public static Iterable<Object[]> data() {
        return Arrays.asList(new Object[][] {
                {
                        null,
                        "Hello World!"
                },
                {
                        "string1",
                        "string1"
                },
                {
                        "string2",
                        "string2"
                }
        });
    }


    @Test
    public void shouldShowCorrectText() {
        Espresso.onView(ViewMatchers.withId(R.id.hello))
                .check(ViewAssertions.matches(ViewMatchers.withText(expectedText)));
    }
}

This will work and it will cover all of our cases, but I don't love this approach. The Parameterized JUnit4 Runner does not delegate to the test runner that you configure via your build system. Furthermore, you cannot name your test methods appropriately. The above example has the following test names: shouldShowCorrectText[0], shouldShowCorrectText[1], and shouldShowCorrectText[2].

The Custom RUNTIME Annotation approach

So lets write this test class in a way that uses the AndroidJUnit4 runner and create sensible test names:

@RunWith(AndroidJUnit4.class)
public class MainActivityTest {

    @Retention(RetentionPolicy.RUNTIME)
    public @interface TestConfig {
        String extraText();
    }

    TestConfig testConfig;

    @Rule
    public final ActivityTestRule<MainActivity> rule
            = new ActivityTestRule<MainActivity>(MainActivity.class) {

        @Override
        public Statement apply(Statement base, Description description) {
            try {
                Method m = MainActivityTest.class.getDeclaredMethod(description.getMethodName());
                testConfig = m.getAnnotation(TestConfig.class);
                return super.apply(base, description);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        }

        @Override
        protected Intent getActivityIntent() {
            if (testConfig == null) {
                return super.getActivityIntent();
            }
            return new Intent(getApplicationContext(), MainActivity.class)
                    .putExtra("text", testConfig.extraText());

        }
    };

    @Test
    public void shouldShowHelloWorldByDefault() {
        verifyText("Hello World!");
    }

    @Test
    @TestConfig(extraText = "Goodbye, Cruel World!")
    public void shouldShowCorrectTextFromExtraWhenSet() {
        verifyText(testConfig.extraText());
    }

    @Test
    @TestConfig(extraText = "Hello, Wonderful World!")
    public void shouldShowCorrectTextFromExtraWhenSetToSomethingElse() {
        verifyText(testConfig.extraText());
    }

    private void verifyText(String text) {
        Espresso.onView(ViewMatchers.withId(R.id.hello))
                .check(ViewAssertions.matches(ViewMatchers.withText(text)));
    }
}

Notice that the Description of the test in the apply(Statement, Description) method comes with the name of the current test method. Therefore, you can get a reference to the Method object and access its annotations.

Conclusion

Because the JUnit4 test lifecycle starts AFTER the Activity under test is resumed, it can be difficult to configure the behavior of the activity prior to the point you can interact with it in the test. There are a few approaches for dealing with this situation, but using a custom RUNTIME annotation can help you configure the test prior to the activity launching with relatively few drawbacks.

Kotlin/Java Annotations: They're where it's @

Ryan — Sat, 11 Jan 2020 22:22:05 +0000

I had an interesting conversation with a colleague recently about the use of annotations in Java/Kotlin code. He had worked in organizations where the use of some language features (in this case, meta-programming via annotations) was discouraged as being "too magical" and "difficult to understand." While it's reasonable to choose to avoid some features of a framework or language because they are generally considered harmful, one developer's "magic" is another developer's everyday productivity tool.

I'll restate the objection to "magic" in a different way:

I don't understand this feature of the language, and therefore I choose to not use it--without regard to its intended usage or possible productivity benefits.

As developers, it's our job to understand both when and how to use the tools we have at our disposal to solve the problems we solve with software. Therefore, keeping an open mind to leverage the features of the language and frameworks we use can be a great productivity aid. This article covers some of the applications of annotations in Kotlin and Java and proposes a few ways to categorize the annotations you see so that you can infer their intended usage.

What are Annotations For?

At a high level, annotations give the compiler information about the code that it is compiling so that the programmer can change its behavior (which is why we use the term "metaprogramming") or to provide extra information about the running code at runtime. Some annotations can serve to generate compilation errors or warnings or even to generate more code for the compiler to compile when combined with annotation processors (which operate at compile time).

Because of this, the properties of the annotations can only be other annotations or values (primitives, strings, arrays of primitives/strings, classes).

What Generic Benefit do Annotations provide?

With annotations, you can write code that is more concise and declarative, and likely less error-prone. They can also enhance the readability of the code by indicating to the developer how the code should be used.

How are Annotations used?

As far as I can tell, their usages can be broken down into the following three categories (I'm using my own nomenclature):

Markers (BINARY/CLASS)
Enrichers (RUNTIME)
Generators (SOURCE)

Markers

Markers are not very sexy, but they are still important. They both inform the reader (of the code) about the nature of the language element (think class, type, field/property. etc) that has been annotated and inform static analysis tools or the compiler about an annotated element. They always included in the class files (this is what is meant by the AnnotationRetention.BINARY/RetentionPolicy.CLASS enum) so that their usages are published with any jar file that is created from the code.

@Deprecated in Java is a marker that is intended to tell a developer that this Element is going to go away, and writing any new code consuming that Element could possibly add more work for you in the future as you will be forced to migrate (usually upon a major version update). Some IDEs use this annotation to make it plain to the user that the element is deprecated. @Deprecated in Kotlin has been enhanced to allow the developer to provide a @ReplaceWith member that will allow some IDEs (IntelliJ/Android Studio) to intelligently replace deprecated code with non-deprecated code. But mostly, this is a tool for the reader of the code.

Another useful marker annotation in Java (even though it has RetentionPolicy.RUNTIME) is @Nonnull (which is part of the outcome of JSR-305). If you use google's implementation, this annotation happens to be useful in Java/Kotlin interop because your Kotlin code will be able to tell that @Nonnull String foo is String in Kotlin and not String?. This also aids in static analysis tooling (such as findbugs) so that null-checks may be skipped. In case you were wondering, this annotation has a companion in @Nullable.

Enrichers

Enrichers add information to a language Element that is readable during runtime (thus, these annotations have AnnotationRetention.RUNTIME/RetentionPolicy.RUNTIME). Say, for example, that you were developing a custom XML serialization/deserialization library with the intention of avoiding your consumers needing to write custom serializer/deserializer classes. Then you could use a small set of annotations combined with a single serializer/deserializer that reads the information contained within the annotations on the Element(s) of the classes its intended to serialize to/from. There is a library that does this: http://simple.sourceforge.net/.

My personal favorite library that leverages runtime annotations is (Retrofit2)[https://square.github.io/retrofit/]. Retrofit2 uses reflection to generate Java Proxy objects capable of performing a network call based solely on your method declaration. For example,

public interface UserService {
  @POST("users/new")
  Call<User> createUser(@Body User user);
}

The @POST and @Body annotations are read at runtime when the call is made, and when this call is executed, retrofit will assemble a URL that corresponds to the endpoint in the @POST annotation and create an OkHttp request that has some serialized form of the User object in the body of the request. (If you don't know how to configure retrofit to do this, I suggest reading the documentation).

That's pretty great, right? In particular on Android, AnnotationRetention.RUNTIME/RetentionPolicy.RUNTIME annotations have a cost: https://blog.nimbledroid.com/2016/02/23/slow-Android-reflection.html. So before you go wild using them for everything--at least on an Android project, be aware of the costs involved.

Generators

Both Kotlin and Java have annotation processing capability. Annotation processors run when your project is compiled (and thus, they alone have visibility into annotations with AnnotationRetention.SOURCE/RetentionPolicy.SOURCE). They can do things as simple as add notes that log output to the console or as complicated as generate code to be compiled. Generators are particularly applicable in situations where traditional reuse patterns break down, and are useful in eliminating boilerplate code.

For example, if you have ever implemented the builder pattern to make instantiation of a class that has many fields easier to understand and more self-documenting, then you're probably familiar with the boilerplate associated with it. You'll find yourself going through a copy-paste-change flow quite often. After 10 or 20 repetitions of this flow, you'll probably have made a mistake somewhere. Then, in order to write reasonable equals, hashCode, and toString methods, you'll have to repeat that flow three more times. You'll also have to write a constructor that understands how to apply the builder to construct your object without accidentally assigning the wrong builder field to the wrong class field.

Enter Google's awesome AutoValue annotation processor: https://github.com/google/auto/blob/master/value/userguide/builders.md. This tool enables you to declare an abstract version of your class and an abstract version of the builder for the class, delegating the implementation details to the annotation processor. Additionally, the equals, hashCode, and toString, methods and the constructor for the class are also generated.

Suppose you now have to add a field to the class. Instead of worrying about keeping the implementation of the constructor, equals,hashCode, andtoString` methods up to date, you just have to declare an abstract method for the class and its builder. Next time you compile your code, the actual implementation will be updated.

But that's not all. AutoValue has been designed to be open for extension, and many AutoValue extensions have been introduced to increase your productivity.

Serialization is a natural extension of AutoValue, and quite a few extensions generate serializers/deserializers the objects of classes that are generated by AutoValue. I'll highlight auto-value-moshi in this article as a representative library because there is an additional Kotlin Annotation Processor called moshi-codegen that will operate on and generate Kotlin classes to serialize/deserialize your Kotlin objects to/from JSON.

Conclusion

It's important to learn how to apply the tools at your disposal to solve the problems that you face as a software developer. Rather than avoid some tools as "magic," you should apply a little learning to demystify them.

Annotations are a useful tool to increase your productivity in Kotlin/Java and increase the quality of your code when used appropriately. So the next time you see some Java/Kotlin that has an @, I hope you'll be more capable of understanding