Learning Android Application Testing

A very simple application has been created to demonstrate the use of some of the tests in this chapter. The source for the application can be downloaded from the Packt website at http://packtpub.com

The following screenshot shows this application running:

When reading the explanation of the tests in this chapter, at any point, you can refer to the demo application that is provided in order to see the test in action. The previous simple application has a clickable link, text input, click on a button and a defined layout UI, we can test these one by one.

Assertions are methods that check for a condition that can be evaluated. If the condition is not met, the assertion method will throw an exception, thereby aborting the execution of the test.

The JUnit API includes the class Assert. This is the base class of all the TestCase classes that hold several assertion methods useful for writing tests. These inherited methods test for a variety of conditions and are overloaded to support different parameter types. They can be grouped together in the following different sets, depending on the condition checked, for example:

The condition tested is pretty obvious and is easily identifiable by the method name. Perhaps the ones that deserve some attention are assertEquals() and assertSame(). The former, when used on objects, asserts that both objects passed as parameters are equally calling the objects' equals() method. The latter asserts that both objects...

The assertions introduced earlier handle a variety of types as parameters, but they are only intended to test simple conditions or simple objects.

For example, we have asertEquals(short expected, short actual) to test short values, assertEquals(int expected, int actual) to test integer values, assertEquals(Object expected, Object expected) to test any Object instance, and so on.

Usually, while testing user interfaces in Android, you will face the problem of more sophisticated methods, which are mainly related with Views. In this respect, Android provides a class with plenty of assertions in android.test.ViewAsserts (see http://developer.android.com/reference/android/test/ViewAsserts.html for more details), which test relationships between Views and their absolute and relative positions on the screen.

These methods are also overloaded to provide different conditions. Among the assertions, we can find the following:

If the assertions that are reviewed previously do not seem to be enough for your tests' needs, there is still another class included in the Android framework that covers other cases. This class is MoreAsserts (http://developer.android.com/reference/android/test/MoreAsserts.html).

These methods are also overloaded to support different parameter types. Among the assertions, we can find the following:

Sometimes, when testing UIs, it is helpful to simulate different kinds of touch events. These touch events can be generated in many different ways, but probably android.test.TouchUtils is the simplest to use. This class provides reusable methods to generate touch events in test cases that are derived from InstrumentationTestCase.

The featured methods allow a simulated interaction with the UI under test. The TouchUtils class provides the infrastructure to inject the events using the correct UI or main thread, so no special handling is needed, and you don't need to annotate the test using @UIThreadTest.

TouchUtils supports the following:

The following test represents a typical usage of TouchUtils:

    public void testListScrolling() {
        listView.scrollTo(0, 0);

        TouchUtils.dragQuarterScreenUp(this, activity); 
      ...

We have seen the mock objects provided by the Android testing framework in Chapter 1, Getting Started with Testing, and evaluated the concerns about not using real objects to isolate our tests from the surrounding environment.

The next chapter deals with Test-driven Development, and if we were Test-driven Development purists, we can argue about the use of mock objects and be more inclined to use real ones. Martin Fowler calls these two styles the classical and mockist Test-driven Development dichotomy in his great article Mocks aren't stubs, which can be read online at http://www.martinfowler.com/articles/mocksArentStubs.html.

Independent of this discussion, we are introducing mock objects as one of the available building blocks because, sometimes, using mock objects in our tests is recommended, desirable, useful, or even unavoidable.

The Android SDK provides the following classes in the subpackage android.test.mock to help us:

This is the base class of all other test cases in the JUnit framework. It implements the basic methods that we were analyzing in the previous examples (setUp()). The TestCase class also implements the junit.framework.Test interface, meaning it can be run as a JUnit test.

Your Android test cases should always extend TestCase or one of its descendants.

public class MyTestCase extends TestCase {
   public MyTestCase() {
      this("MyTestCase Default Name");
   }

   public MyTestCase(String name...

This class can be used as a base class for general-purpose Android test cases.

Use it when you need access to Android resources, databases, or files in the filesystem. Context is stored as a field in this class, which is conveniently named mContext and can be used inside the tests if needed, or the getContext() method can be used too.

Tests based on this class can start more than one Activity using Context.startActivity().

There are various test cases in Android SDK that extend this base class:

When using the AndroidTestCase Java class, you inherit some base assertion methods that can be used; let's look at these in more detail.

public void assertActivityRequiresPermission(String packageName, String className, String permission)

Instrumentation is instantiated by the system before any of the application code is run, thereby allowing monitoring of all the interactions between the system and the application.

As with many other Android application components, instrumentation implementations are described in the AndroidManifest.xml under the tag <instrumentation>. However, with the advent of Gradle, this has now been automated for us, and we can change the properties of the instrumentation in the app's build.gradle file. The AndroidManifest file for your tests will be automatically generated:

defaultConfig {
  testApplicationId 'com.blundell.tut.tests'
testInstrumentationRunner  "android.test.InstrumentationTestRunner"
}

The values mentioned in the preceding code are also the defaults if you do not declare them, meaning that you don't have to have any of these parameters to start writing tests.

The testApplicationId attribute defines the name of the package for your tests. As a default, it is your...

The InstrumentationTestCase class is the direct or indirect base class for various test cases that have access to Instrumentation. This is the list of the most important direct and indirect subclasses:

The InstrumentationTestCase class is in the android.test package, and extends junit.framework.TestCase, which extends junit.framework.Assert.

public final T launchActivity (String pkg, Class<T> activityCls, Bundle extras)

This is mainly a class that holds common code for other test cases that access Instrumentation.

You can use this class if you are implementing a specific behavior for test cases and the existing alternatives don't fit your requirements. This means you are unlikely to use this class unless you want to implement a new base class for other tests to use. For example, consider a scenario where Google brings out a new component and you want to write tests around it (like SuperNewContentProvider).

If this is not the case, you might find the following options more suitable for your requirements:

The abstract class android.test.ActivityTestCase extends android.test.InstrumentationTestCase and serves as a base class for other different test cases, such as android.test.ActivityInstrumentationTestCase, android.test.ActivityInstrumentationTestCase2, and android.test.ActivityUnitTestCase...

The ActivityInstrumentationTestCase2 class would probably be the one you use the most to write functional Android test cases. It provides functional testing of a single Activity.

This class has access to Instrumentation and will create the Activity under test using the system infrastructure, by calling InstrumentationTestCase.launchActivity(). The Activity can then be manipulated and monitored after creation.

If you need to provide a custom Intent to start your Activity, before invoking getActivity(), you may inject an Intent with setActivityIntent(Intent intent).

This test case would be very useful to test interactions through the user interface as events can be injected to simulate user behavior.

ActivityInstrumentationTestCase2(Class<T> activityClass)

This is a test case designed to test the ContentProvider classes.

The ProviderTestCase2 class also extends AndroidTestCase. The class template parameter T represents ContentProvider under test. Implementation of this test uses IsolatedContext and MockContentResolver, which are mock objects that we described before in this chapter.

ProviderTestCase2(Class<T> providerClass, String providerAuthority)

public void testQuery() {
    String segment = "dummySegment";
    Uri uri = Uri.withAppendedPath(MyProvider.CONTENT_URI,...

This is a test case specially created to test services. The methods to exercise the service life cycle, such as setupService, startService, bindService, and shutDownService, are also included in this class.

ServiceTestCase(Class<T> serviceClass)

The TestSuiteBuilder.FailedToCreateTests class is a special TestCase class used to indicate a failure during the build() step. That is, during the test suite creation, if an error is detected, you will receive an exception like this one, which indicates the failure to construct the test suite:

INFO/TestRunner(1): java.lang.RuntimeException: Exception during suite construction
INFO/TestRunner(1):     at android.test.suitebuilder.TestSuiteBuilder$FailedToCreateTests.testSuiteConstructionFailed(TestSuiteBuilder.java:239)
INFO/TestRunner(1):     at java.lang.reflect.Method.invokeNative(Native Method)
[...]
INFO/TestRunner(1):     at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:520)
INFO/TestRunner(1):     at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447)

Your Android project might require an external Java library or an Android library. Now, we will explain how to incorporate these in your project that is ready to be tested. Note that the following explains the usage of a local module that is an Android library, but the same rules can be applied to an external JAR (Java library) file or an external AAR (Android library) file.

Let's pretend that in one Activity, we are creating objects from a class that is part of a library. For the sake of our example, let's say the library is called dummyLibrary, and the mentioned class is Dummy.

So our Activity would look like this:

import com.blundell.dummylibrary.Dummy;

public class MyFirstProjectActivity extends Activity {
    private Dummy dummy;

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

        final EditText messageInput = (EditText) findViewById(R...

We investigated the most relevant building blocks and reusable patterns to create our tests. Along this journey, we:

Now that we have all the building blocks, it is time to start creating more and more tests to acquire the experience needed to master the technique.

The next chapter will provide you with examples of when and where to use different test cases on Android. This will give us a great breadth of expertise in knowing what testing methodology to apply when we have a specific scenario to test.