Android Testing Point

The test application demonstrates these key points:

• An Android test is itself an Android application that is linked to the application under test by entries in its AndroidManifest.xml file.
• //一个Android的测试本身是由被测项目在AndroidManifest.xml文件链接到应用程序的Android应用程序, 这句话说明了两个问题: 测试本身也是安卓的一个应用; 
• Instead of Android components, an Android test application contains one or more test cases. Each of these is a separate class definition.
• //一个安卓的测试应用包括一个或多个测试集合用来代替安卓的模块.每一个都是一个独立的类定义.
• Android test case classes extend the JUnit TestCase class.
• //安卓的测试集合继承自JUnit TestCase类.
• Android test case classes for activities extend JUnit and also connect you to the application under test with instrumentation. You can send keystroke or touch events directly to the UI.
• //对于activities的测试类继承自JUnit并且也能使你在测试集下使用instrumentation.你可以直接操作UI通过输入和触碰事件.
• You choose an Android test case class based on the type of component (application, activity, content provider, or service) you are testing.
• //你可以选择在一个组件(application, activity, content provider, or service)的基础上进行你的测试.
• Additional test tools in Eclipse/ADT provide integrated support for creating test applications, running them, and viewing the results.
• //除此之外, 在Eclipse/ADT 的工具能够支持创建测试应用, 跑测试和查看结果的集成套件

The test application contains methods that perform the following tests:

• Initial conditions test. Tests that the application under test initializes correctly. This is also a unit test of the application‘s onCreate() method. Testing initial conditions also provides a confidence measure for subsequent tests.
• //初始条件化的测试.在测试初始化正确下测试应用. 这也是一个应用的onCreate() 方法的单元测试.测试初始条件也包括了一个在随后的测试中提供一个可行的度量.
• UI test. Tests that the main UI operation works correctly. This test demonstrates the instrumentation features available in activity testing. It shows that you can automate UI tests by sending key events from the test application to the main application.
• //UI测试.测试那些能够被正确操作的主要UI.这个测试主要在activity测试中展示instrumentation特性的可用性. 它展示了你能够通过从测试应用发送主要事件到主要应用的方式自动化UI测试.
• State management tests. Test the application‘s code for saving state. This test demonstrates the instrumentation features of the test runner, which are available for testing any component.
• 申明管理测试集. 为了保存状态而测试应用的代码.这个测试展示了test runner的instrumentation的功能, 它能够对于测试任何组件可用.

The next step is to define the test case class. In this tutorial, you‘ll be creating a test case class that includes:

• Test setup. This use of the JUnit setUp() method demonstrates some of the tasks you might perform before running an Android test.

• • getActivity(). Gets a reference to the activity under test (SpinnerActivity). This call also starts the activity if it is not already running.
  • findViewById(int). Gets a reference to the Spinner widget of the application under test.
  • getAdapter(). Gets a reference to the adapter (an array of strings) backing the spinner.

Add this code to the definition of SpinnerActivityTest, after the constructor definition:

  @Override
  protected void setUp() throws Exception {
    super.setUp();

    setActivityInitialTouchMode(false);

    mActivity = getActivity();

    mSpinner =
      (Spinner) mActivity.findViewById(
        com.android.example.spinner.R.id.Spinner01
      );

      mPlanetData = mSpinner.getAdapter();

  } // end of setUp() method definition

• Testing initial conditions. This test demonstrates a good testing technique. It also demonstrates that with Android instrumentation you can look at the application under test before the main activity starts. The test checks that the application‘s important objects have been initialized. If the test fails, you then know that any other tests against the application are unreliable, since the application was running in an incorrect state.

  Note: The purpose of testing initial conditions is not the same as using setUp(). The JUnit setUp() runs once beforeeach test method, and its purpose is to create a clean test environment. The initial conditions test runs once, and its purpose is to verify that the application under test is ready to be tested.

The initial conditions test verifies that the application under test is initialized correctly. It is an illustration of the types of tests you can run, so it is not comprehensive. It verifies the following:

• The item select listener is initialized. This listener is called when a selection is made from the spinner.
• The adapter that provides values to the spinner is initialized.
• The adapter contains the right number of entries.

The actual initialization of the application under test is done in setUp(), which the test runner calls automatically before every test. The verifications are done with JUnit Assert calls. As a useful convention, the method name istestPreConditions():

  public void testPreConditions() {
    assertTrue(mSpinner.getOnItemSelectedListener() != null);
    assertTrue(mPlanetData != null);
    assertEquals(mPlanetData.getCount(),ADAPTER_COUNT);
  } // end of testPreConditions() method definition

Add this member:

  public static final int ADAPTER_COUNT = 9;

• Testing the UI. This test shows how to control the main application‘s UI with instrumentation, a powerful automation feature of Android testing.

• Testing state management. This test shows some techniques for testing how well the application maintains state in the Android environment. Remember that to provide a satisfactory user experience, your application must never lose its current state, even if it‘s interrupted by a phone call or destroyed because of memory constraints. The Android activity lifecycle provides ways to maintain state, and the SpinnerActivity application uses them. The test shows the techniques for verifying that they work.