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 {@link android.app.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 {@link android.app.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.
{@link android.app.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:
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 {@link junit.framework.TestCase#setUp()} and {@link junit.framework.TestCase#tearDown()} methods in your test. The test runner automatically runs {@link junit.framework.TestCase#setUp()} before running any other test methods, and {@link junit.framework.TestCase#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:
For example:
public class MyFirstTestActivityTest
extends ActivityInstrumentationTestCase2<MyFirstTestActivity> {
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 {@link junit.framework.TestCase#setUp()} method is invoked by the test runner before it runs any tests in the test class.
Typically, in the {@link junit.framework.TestCase#setUp()} method, you should:
You can use the {@link android.test.ActivityInstrumentationTestCase2#getActivity()} method to get a reference to the {@link android.app.Activity} under test.
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 {@code testPreconditions()}.
For example, you might want to add a {@code 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 {@link junit.framework.Assert} class. Generally, you can use assertions to verify if a specific condition that you want to test is true.
In both cases, the test runner proceeds to run the other test methods in the test case.
Next, add one or more test methods to verify the layout and functional behavior of your {@link android.app.Activity}.
For example, if your {@link android.app.Activity} includes a {@link android.widget.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 {@code testMyFirstTestTextView_labelText()} method simply checks that the default text of the {@link android.widget.TextView} that is set by the layout is the same as the expected text defined in the {@code 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 {@link junit.framework.Assert#assertEquals(java.lang.String, java.lang.String) assertEquals()} method. If the values are not the same, the assertion will throw an {@link junit.framework.AssertionFailedError} exception.
If you added a {@code testPreconditions()} method, put your test methods after the {@code testPreconditions()} definition in your Java class.
For a complete test case example, take a look at {@code MyFirstTestActivityTest.java} in the sample app.
You can build and run your test easily from the Package Explorer in Eclipse.
To build and run your test:
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.