Please note that the contents of this offline web site may be out of date. To access the most recent documentation visit the online version .
Note that links that point to online resources are green in color and will open in a new window.
We would love it if you could give us feedback about this material by filling this form (You have to be online to fill it)

Creating and Running a Test Case

In order to verify that there are no regressions in the layout design and functional behavior in your application, it's important to create a test for each Activity in your application. For each test, you need to create the individual parts of a test case, including the test fixture, preconditions test method, and Activity test methods. You can then run your test to get a test report. If any test method fails, this might indicate a potential defect in your code.

Note: In the Test-Driven Development (TDD) approach, instead of writing most or all of your app code up-front and then running tests later in the development cycle, you would progressively write just enough production code to satisfy your test dependencies, update your test cases to reflect new functional requirements, and iterate repeatedly this way.

Create a Test Case

Activity tests are written in a structured way. Make sure to put your tests in a separate package, distinct from the code under test.

By convention, your test package name should follow the same name as the application package, suffixed with ".tests" . In the test package you created, add the Java class for your test case. By convention, your test case name should also follow the same name as the Java or Android class that you want to test, but suffixed with “Test” .

To create a new test case in Eclipse:

  1. In the Package Explorer, right-click on the /src directory for your test project and select New > Package .
  2. Set the Name field to <your_app_package_name>.tests (for example, com.example.android.testingfun.tests ) and click Finish .
  3. Right-click on the test package you created, and select New > Class .
  4. Set the Name field to <your_app_activity_name>Test (for example, MyFirstTestActivityTest ) and click Finish .

Set Up Your Test Fixture

A test fixture consists of objects that must be initialized for running one or more tests. To set up the test fixture, you can override the setUp() and tearDown() methods in your test. The test runner automatically runs setUp() before running any other test methods, and tearDown() at the end of each test method execution. You can use these methods to keep the code for test initialization and clean up separate from the tests methods.

To set up your test fixture in Eclipse:

  1. In the Package Explorer, double-click on the test case that you created earlier to bring up the Eclipse Java editor, then modify your test case class to extend one of the sub-classes of ActivityTestCase .

    For example:

             public class MyFirstTestActivityTest
            extends ActivityInstrumentationTestCase2<MyFirstTestActivity> {
            
  2. Next, add the constructor and setUp() methods to your test case, and add variable declarations for the Activity that you want to test.

    For example:

             public class MyFirstTestActivityTest
            extends ActivityInstrumentationTestCase2<MyFirstTestActivity> {
    
        private MyFirstTestActivity mFirstTestActivity;
        private TextView mFirstTestText;
    
        public MyFirstTestActivityTest() {
            super(MyFirstTestActivity.class);
        }
    
        @Override
        protected void setUp() throws Exception {
            super.setUp();
            mFirstTestActivity = getActivity();
            mFirstTestText =
                    (TextView) mFirstTestActivity
                    .findViewById(R.id.my_first_test_text_view);
        }
    }
            

    The constructor is invoked by the test runner to instantiate the test class, while the setUp() method is invoked by the test runner before it runs any tests in the test class.

Typically, in the setUp() method, you should:

  • Invoke the superclass constructor for setUp() , which is required by JUnit.
  • Initialize your test fixture state by:
    • Defining the instance variables that store the state of the fixture.
    • Creating and storing a reference to an instance of the Activity under test.
    • Obtaining a reference to any UI components in the Activity that you want to test.

You can use the getActivity() method to get a reference to the Activity under test.

Add Test Preconditions

As a sanity check, it is good practice to verify that the test fixture has been set up correctly, and the objects that you want to test have been correctly instantiated or initialized. That way, you won’t have to see tests failing because something was wrong with the setup of your test fixture. By convention, the method for verifying your test fixture is called testPreconditions() .

For example, you might want to add a testPreconditons() method like this to your test case:

       public void testPreconditions() {
    assertNotNull(“mFirstTestActivity is null”, mFirstTestActivity);
    assertNotNull(“mFirstTestText is null”, mFirstTestText);
}
      

The assertion methods are from the JUnit Assert class. Generally, you can use assertions to verify if a specific condition that you want to test is true.

  • If the condition is false, the assertion method throws an AssertionFailedError exception, which is then typically reported by the test runner. You can provide a string in the first argument of your assertion method to give some contextual details if the assertion fails.
  • If the condition is true, the test passes.

In both cases, the test runner proceeds to run the other test methods in the test case.

Add Test Methods to Verify Your Activity

Next, add one or more test methods to verify the layout and functional behavior of your Activity .

For example, if your Activity includes a TextView , you can add a test method like this to check that it has the correct label text:

       public void testMyFirstTestTextView_labelText() {
    final String expected =
            mFirstTestActivity.getString(R.string.my_first_test);
    final String actual = mFirstTestText.getText().toString();
    assertEquals(expected, actual);
}
      

The testMyFirstTestTextView_labelText() method simply checks that the default text of the TextView that is set by the layout is the same as the expected text defined in the strings.xml resource.

Note: When naming test methods, you can use an underscore to separate what is being tested from the specific case being tested. This style makes it easier to see exactly what cases are being tested.

When doing this type of string value comparison, it’s good practice to read the expected string from your resources, instead of hardcoding the string in your comparison code. This prevents your test from easily breaking whenever the string definitions are modified in the resource file.

To perform the comparison, pass both the expected and actual strings as arguments to the assertEquals() method. If the values are not the same, the assertion will throw an AssertionFailedError exception.

If you added a testPreconditions() method, put your test methods after the testPreconditions() definition in your Java class.

For a complete test case example, take a look at MyFirstTestActivityTest.java in the sample app.

Build and Run Your Test

You can build and run your test easily from the Package Explorer in Eclipse.

To build and run your test:

  1. Connect an Android device to your machine. On the device or emulator, open the Settings menu, select Developer options and make sure that USB debugging is enabled.
  2. In the Project Explorer, right-click on the test class that you created earlier and select Run As > Android Junit Test .
  3. In the Android Device Chooser dialog, select the device that you just connected, then click OK .
  4. In the JUnit view, verify that the test passes with no errors or failures.

For example, if the test case passes with no errors, the result should look like this:

Figure 1. Result of a test with no errors.