Android Unit Test

Espresso

Espresso is the newest testing framework for Android, also it is not so fresh anymore, I guess it appears in Lollipop time. According to the official document, it can write concise, beautiful, and reliable Android UI tests.

@Test
public void greeterSaysHello() {
  onView(withId(R.id.name_field))
    .perform(typeText("Steve"));
  onView(withId(R.id.greet_button))
    .perform(click());
  onView(withText("Hello Steve!"))
    .check(matches(isDisplayed()));
}

Apparently, it’s concise and beautiful syntax comes from the functional coding styles, whether it is reliable, I can not get the conclusion from the above syntax. I think it is the replacement of the deprecated Instrumentation TestCase, so it should be much advanced than the older one. And according to the Chui-Ki Chen’s presentation, it does automatic synchronization of test action with app UI, which is the big breakthrough compared with the deprecated Instrumentation Test Case.

Then, How to write those beautiful functional syntax test case? The Espresso is great, but not easy to learn at first. It becomes concise and beautiful to me after I read Chui-Ki Chen’s article. But before that, the Espresso is a nightmare to a unit test newbie.

There is a formula for Espresso test case.

onView(ViewMatcher)
  .perform(ViewAction)
  .check(ViewAssertion);

Then, that’s all need to master to write a test case, But how to bind the test case to the target Activity?

@RunWith(AndroidJUnit4.class)
public class MainActivityTest {
  @Rule
  public ActivityTestRule<MainActivity> activityRule = new ActivityTestRule<>(

                                                               MainActivity.class);

  @Test
  public void done() {
    
    onView(withId(R.id.text))
        .check(matches(withText(R.string.done)));
  }
}

The much more advanced topic of the Espresso is how to write customized ViewMatcher, ViewAction, and ViewAssertion, and also test AdapterView and RecyclerView. Chui-Ki Chen’s presentation has a tutorial about those topics.

Idling Resource

The Espresso is reliable than Instrumentation TestCase because it does automatic synchronization of test action with app UI, it can do that synchronization between test case and UI rendering by inventing the idling resource mechanism.

By default, it already has the idling resource observations inside to observe the UI queue, AsyncTask pool, and some unknown asychronized resources. What if you want your own idling resource observation, for example, wait for an HTTP request return. Then define your customized idling resources.

Mockito and Mock Application

Mockito is used to simulate object’s behavior, it is useful in the unit test. A unit test is to test a unit in an isolated environment, but how to separate the unit from the context, it can be a software architecture issue. That’s the benefit of the unit test, and also the reason convinces me to write unit test.

Back to Mockito, it is the effective way to isolate different units in software, but only in a good architecture. There are already some elegant dependency management architectures and also effective dependency design. In conclusion, Mockito should be combined with a custom AndroidJUnitRunner, in the custom AndroidJUnitRunner, it provides a different Mock Application, which replaces the dependency object with a fake mocked one.

I learned those from the following demo project.

https://github.com/chiuki/android-test-demo