[Android test] Test Basics

Address: http://developer.android.com/tools/testing/testing_android.html

The android testing framework is part of the development environment. It provides an architecture and a useful tool to help developers test each part of an application from a unit to a framework.

This testing framework has the following important features:

• The android test suite is based on JUnit. You can use pure JUnit to test a class or android JUnit extension to test the android component. If you are new to Android testing, you can useAndroidTestCaseClass, and then use more complex classes.
• The JUnit extension of Android provides test case classes for different components ). These classes provide methods to create virtual objects and help developers control the life cycle of components.
• Test suites are included in a test package similar to the main application package, so you don't have to relearn a set of tools and techniques for designing and compiling tests.
• The compiled and tested SDK tool is available in eclipse with ADT installed. You can also use it in the form of command line when using other ides. These tools obtain information from the project of the application to be tested and automatically create the compilation file, manifest file, and file directory for the test package.
• The SDK provides the monkeyrunner tool, which is an API for testing devices using python. The SDK also provides the UI/Application Exerciser monkey tool, which is a command line tool that sends pseudo-random events to devices for stress testing on the UI.

This document describes the basis of the android testing framework, including the structure of the test code, APIs for development and testing, and tools for developers to start and view the test results. This document assumes that you have the foundation for Android Application Programming and JUnit testing.

The following figure briefly depicts the andorid test framework:

Test Structure

Android compilation and testing tools assume that the test project has been organized into a standard structure such as testing, testing, testing packages, and testing projects.

Android testing is based on JUnit. Generally, a JUnit test is a method used to test "a part of the application to be tested. Developers place these test methods in a class called test cases (or test suites. Each test is an independent test of a separate module in the application to be tested. Each class is a container of similar test methods. Generally, it also provides additional auxiliary methods.

In JUnit, the developer compiles one or more test source files to one class file. Similarly, in Android, developers use Android compilation tools to compile one or more test source files in the test package as class files. In JUnit, developers use test runner to execute test classes ). In Android, developers can use test tools to load test packages and applications to be tested. Then, the test tool will call test runner specific to Android.

Test Project

Similar to Android applications, tests are organized as projects.

A test project is a directory or Eclipse project where developers create source code, manifest files, and other files of the test package. The android SDK provides developers with tools to create and update test projects, including command lines and eclipse with ADT. Tools help you create directories that store the source code, resource files, and manifest files of the test project. The command line tool also creates an ant compilation file.

Developers should always use the android tool to create a new test project. The tool can do the following:

• Automatically help configure test package usageInstrumentationTestRunnerAs a test case runner, developers must useInstrumentationTestRunnerOr its subclass to execute JUnit
  Test.
• Obtain a proper name for the test package. If the package to be tested is named COM. mydomain. myApp and Android tool automatically name the test package COM. mydomain. myApp. test, which helps developers identify the relationships between them and avoid conflicts.
• Automatically create appropriate compilation files, manifest files, and directory structures for the test project. It helps developers compile the test package without modifying the compilation file and configuring the relationship between the test package and the application to be tested.

You can create a test project anywhere in the file system, but the best practice is to add a test project, in this way, the root directory of the test project, tests/, is at the same level as the src/directory of the application to be tested. This will help you find the test items associated with the application. For example, if the root directory of your application project is myproject, you should use the following directory structure:

  MyProject/      AndroidManifest.xml      res/          ... (resources for main application)      src/          ... (source code for main application) ...      tests/          AndroidManifest.xml          res/              ... (resources for tests)          src/              ... (source code for tests)

Test API

The android testing API is based on the JUnit testing API and extends an instrumentation framework and a test class specific to Android.

JUnit

You can use JUnit'sTestCaseClass performs unit tests on classes that do not use Android APIs, and testcase is alsoAndroidTestCaseYou can use it to test Android-dependent objects. Besides providing the JUnit framework,AndroidTestCaseProvides Android-specific
Setup, teardown, and other methods.

You can use JUnit'sAssertClass to display the results. The assert method compares your expectations with the actual results and throws an exception when the comparison fails. Android also provides an asserted class that extends the comparison type and an asserted class that is used to test the UI.
The detailed description of assertion classes.

You can read the documents on the junit.org homepage to learn more about JUnit. Note that the android test API supports the code style of JUnit 3 and does not support JUnit 4. At the same time, you must use test runner of AndroidInstrumentationTestRunnerTo run the test class. This test
Runner is described in the running tests section.

Instrumentation

Android instrumentation is a series of hooks in the Android system ). These hooks can control an android component from the normal life cycle of the component. It also controls how Android loads applications.

Generally, an android component runs according to the lifecycle specified by the system. For example, the lifecycle of an activity starts when it is activated by an intent, and its oncreate () the method will be called, followed by onresume (). When the user starts another application, the onpause () method will be called. If the activity calls the finish () method, its ondestroy () method () the method is also called. The android framework API does not provide methods for you to directly call these callback methods in code, but you can use instrumentation.

At the same time, the system runs all the components in an application in the same process. You can run some components, such as content provider, in a separate process. However, you cannot force an application to run in the same process as another running application.

With Android imstrumentation, you can call the callback method directly in the test code. It allows you to run the lifecycle of a component step by step, just as you are debugging the component. The following test code demonstrates how to use instrumentation to test the SAVE and restore status of an activity:

    // Start the main activity of the application under test    mActivity = getActivity();    // Get a handle to the Activity object's main UI widget, a Spinner    mSpinner = (Spinner)mActivity.findViewById(com.android.example.spinner.R.id.Spinner01);    // Set the Spinner to a known position    mActivity.setSpinnerPosition(TEST_STATE_DESTROY_POSITION);    // Stop the activity - The onDestroy() method should save the state of the Spinner    mActivity.finish();    // Re-start the Activity - the onResume() method should restore the state of the Spinner    mActivity = getActivity();    // Get the Spinner's current position    int currentPosition = mActivity.getSpinnerPosition();    // Assert that the current position is the same as the starting position    assertEquals(TEST_STATE_DESTROY_POSITION, currentPosition);

A key method used in the Code isgetActivity()It is the content in the android instrumentation API. The activity to be tested will not be started until you call this method. You can configure the environment (test fixture) required for the test in advance, and then call this method to start the activity.

At the same time, instrumentation can load the test package and the tested application to the same process. Because the components and tests of the application are in the same process, the test code can call the method of the application component to modify and check the attributes of the component.

Test Case class

Android provides severalTestCaseAndAssertThey all have setup, teardown and other auxiliary methods unique to andorid.

Androidtestcase

A common test case class, especially when you are learning Android testingAndroidTestCaseStart. It inheritsTestCaseAndAssertClass. It provides the setup () and teardown () methods in the standard JUnit, as well as all the assert methods of JUnit. In addition, it provides methods to test permissions and methods to prevent memory leakage by clearing certain class references.

Test Cases unique to components

An important feature of the android testing framework, even though the test cases class exclusive to components. These unique component tests require methods to control the life cycle of components configured before and recycled after testing. They also provide methods for creating simulated objects. These classes will be described in the specific test content of the component:

• Activity Testing
• Content Provider Testing
• Service Testing

Android does not provide a separate test case class for broadcastreceiver. You can test the broadcastreceiver by testing the component that sends the intent object to it and check whether the broadcastreceiver reply is correct.

Applicationtestcase

You can useApplicationTestCaseThis test case class is used for testingApplicationObject startup and exit. These objects maintain the global status of all component information in the application package.
Use Case to verify that the <Application> element in the manifest file is correctly configured. However, remember that this test case cannot control the testing of application package components.

Instrumentationtestcase

If you want to use the instrumentation method in a test case class, you must useInstrumentationTestCaseOr its subclass. The test case of the activity inherits the base class and extends some auxiliary activity testing functions.

Assertion class

Because the android test case class inherits from JUnit, you can use assertions to display the test results. The assertion method compares the actual value returned by the test with the expected value. If the comparison fails, an assertionexception is thrown. Using assertion is more convenient than printing logs, and provides better test performance.

Except for JUnit'sAssertClass method, the test API also providesMoreAssertsAndViewAssertsClass:

• MoreAssertsMore powerful assertions, such as regular expression matchingassertContainsRegex(String,
String).
• ViewAssertsContains a lot of assertions about the view, for example, it contains a view that is used to test whether a view is at a specific (x, y) Position on the screenassertHasScreenCoordinates(View,
View, int, int)These assertions simplify the integration and targeting tests in the UI.

Simulated Object Class

To solve the dependencies during the test, Android provides classes for creating simulated system objects, suchContextObject,ContentProviderObject,ContentResolverObject andServiceObject. Some
Test Case also provides simulatedIntentObject. By using these simulated objects, you can isolate the test from the rest of the system and satisfy the dependencies in the test.android.testAndandroid.test.mock.

Simulated objects are isolated from running systems by not using them or overwriting normal operations. For example,MockContentResolverThe object uses its own local framework isolated from the system to replace the normal resolver framework. Mockcontentresolver does not usenotifyChange(Uri,
ContentObserver, boolean)In this way, the observer objects outside the test environment will not be triggered by exceptions.

The simulated object class satisfies the test dependency by providing subclass of the normal class. This subclass does not work except the method you override. For example,MockResourcesObject provisionResourcesA subclass of A Class. Each method throws an exception during the call. To use it, you only need to override the required method.

The following lists the simulated object classes available in Android:

Basic Simulated Object Class

MockApplication,MockContext,MockContentProvider、MockCursor,、MockDialogInterface,Mockpackagemanager and mockresourcesProvides a simple and useful simulation policy. They are the "method unavailable" version of the corresponding class in the system, and all their methods will be thrown during the call.UnsupportedOperationExceptionException. To use them, you need to overwrite the methods used to meet the requirements of dependencies.

Note:MockContentProviderAndMockCursorYes API Level 8
The newly added API.

Resolver Simulated Object

MockContentResolverBy shielding the normal resolver framework of the system, the content provider is provided with an isolated test. Mockcontentresolver does not search for the content provider that provides authority in the system, but uses its own internal table. You must explicitly useaddProvider(String,
ContentProvider)Method to add the provider to the table.

With this feature, you can associate a simulated content provider with an authority to create a new provider object using test data. You can even set the authority of the provider to null. In fact, the mockcontentresolver object isolates your test from the provider that contains real data. You can control the provider function or prevent testing from affecting real data.

Context used for testing

Android provides two context classes for testing:

• IsolatedContextClass provides an isolatedContextThe files, directories, and database operations using the context are all in a separate test area. Despite limited functionality, this class is sufficient for system calls (this
  Context has enough stub code to respond to system CILS ). This class allows you to test application data operations without affecting the real data on the current device.
• RenamingDelegatingContextProvides such a context, most of its functions are composed of an existingContextBut the file and database operations are composedIsolatedContextThe isolated part uses a test directory and creates a special file and directory name. You can control the name by yourself or enable the constructor to automatically specify it. This class provides a quick way to create an isolated region for data operations without affecting other normal operations of context.

Run the test

Test Case is run by a test runner class. Test runner loads the test case class, initializes, runs, and cleans up each test. The android test runner must be registered (must be instrumented), so that the system function of starting the application can control how the test package loads the test case and the tested package. You can set a value in the manifest file of the test package to tell the system which registered test runner is used.

InstrumentationTestRunnerIs the main test runner class in Android, which extends the JUnit test runner framework and is registered. It can execute all the test case classes provided by the Android system and support all types of tests.

You can specify the manifest file of the test package<instrumentation>The label content is instrumentation or its subclass.InstrumentationTestRunnerCode in the Shared Libraryandroid.test.runnerSo it is usually not linked to your code, you must<uses-library>Label. You don't know how to manually set these labels, such as eclipse with ADT and Android
The command line tool automatically generates them and adds them to the manifest file of the test package.

Note: If you are usingInstrumentationTestRunnerYou must manually modify the <instrumentation> label and point it to the class you want to use.

To runInstrumentationTestRunnerClass must use Android tools to call internal hidden system classes. When you use eclipse with ADT to perform the test, these classes are automatically called. When you use the command line tool to perform the test, you can use android
Debug bridge (ADB) runs these classes.

The system class loads and starts a test package, kills the running process of the tested application package, reloads the entity of the tested package, and then gives controlInstrumentationTestRunnerTo run each test case in the test package. You can also use setting in eclipse or flag in the command line tool to control which
Test Case or method is running.

Neither the system class norInstrumentationTestRunnerRun the tested package. This is done by test case. It either calls the method in the tested package or calls its own method that can change the lifecycle of the tested package. The application is completely controlled by test case. Before a test starts, test case initializes the test environment. The previous test shows the code of a spinner activity.
Snippet has a demo.

For more running tests, see testing from eclipse with ADT and testing from other ides.

View test results

The android testing framework returns the test result to the tool that starts the test. If you run the test in eclipse with ADT, the result is displayed in a new JUnit view panel. If you start the test from the command line, the result is displayed in stdout. In either case, you can see a brief summary of each test case name and the method you are running. You can also see all the assertions of failure, it contains a link to the row where the failed test code is located. Failure assertions also list the expected values and actual values.

The test results are in different formats based on the IDE you are using. The test result format of eclipse with ADT is described in testing from eclipse with ADT. The test result format that starts running from the command line is in testing.
The from other ides section is described.

Monkey and monkeyrunner

The SDK provides two practical application testing tools:

• UI/Application Exerciser monkey, usually called "monkey", is a command line tool that sends pseudo-random event streams (such as keys, touch, and gestures) to devices. You can run it through Android debug bridge (ADB), perform stress tests on the application, and report errors. You can run the same random number seed every time to repeat the event stream.
• Monkeyrunner is an API and a runtime environment for testing programs written in Python. This API provides the following functions: connect to a device, install and uninstall software packages, compare two images (comparing two images), and run the test application corresponding to the application. With this API, you can write out powerful and complex tests. The program using this API can run through the command line tool monkeyrunner.

Processing Package name

Throughout the test environment, you must simultaneously process the Android app package name and Java package identifier. They all use the same naming format, but they represent completely different entities. To correctly start the test, you need to know the differences between them.

The androidpackage name is a unique system name corresponding to the .apk file. It is set by the "Android: Package" attribute in the <manifest> label of the manifest file of the application package. The name of the test package must be different from that of the tested package. Generally, the android tool adds ". Test" to the name of the tested package.

The test package also uses the package name to locate the application to be tested, which is set by the "Android: targetpackage" attribute of the <instrumentation> element in the manifest file of the test package.

A Java package identifier corresponds to a source file. The package name reflects the directory where the source file is located. It also affects the accessibility between classes and members.

The android tool used to create a test project will help you set the name of a test package. Based on your input, the tool sets the name of the test package and the name of the test target package. These tools work only when the tested application project already exists.

By default, these tools set the package identifier of the test class to be consistent with the package identifier of the tested application. If you want to expose some Members in the tested package, you may need to make some modifications. If you want to modify, only modify the Java package identifier, do not modify the android package name, only modify the source file of test case, and do not modify the R. the package name of the Java file, because modifying it will cause the R. java class conflict. Do not change the android package name of the test package to the same name as the package name of the application it tests, because their names are no longer unique in the system.

Test What

What to test describes in detail the key functions that should be tested in an Android Application and the status that may affect this function.

Most unit tests are specific to the andorid component you are testing. Activity testing, content provider testing, and
The service testing section lists "what to test ".

If yes, you should run these tests on a real device. If not, you can use Android emulator to load the hardware, screen, and version Android vitual device that you want to test.

Next

To learn how to configure and run the test in eclipse, see testing from eclipse with ADT. If you are not using eclipse for development, see testing from other ides.

For more information about Android testing, see activity testing tutorial.