android自动化测试之Junit
来源：互联网 发布：志成软件 编辑：程序博客网 时间：2024/06/06 08:24
Activity测试部分依赖于Android instrumentation framework.不像其它的components, activity有生命周期向界面发送事件是通过instrumentation.
如果测试的过程中要把自动锁键盘去掉，则需要在xml文件中加
建立测试工程可以用android工具或eclipse,用android工具是
android create test-project -m <main_path> -n <project_name> -p <test_path>
详细见:
%android-sdk%\docs\guide\developing\testing\testing_otheride.html
http://developer.android.com\guide\developing\testing\testing_otheride.html
<manifest>
<uses-permission android:name="android.permission.DISABLE_KEYGUARD"/>
</manifest>
然后再想测试的activitiesde的onCreate()中加下面的代码
mKeyGuardManager = (KeyguardManager) getSystemService(KEYGUARD_SERVICE);
mLock = mKeyGuardManager.newKeyguardLock("activity_classname");
mLock.disableKeyguard();
The Activity Testing API
%android-sdk%\docs\reference\android\test\InstrumentationTestCase.html
http://developer.android.com\reference\android\test\InstrumentationTestCase.html
基类是InstrumentationTestCase
The activity testing classes also provide the JUnit framework by extendingTestCase andAssert.
The two main testing subclasses are ActivityInstrumentationTestCase2 andActivityUnitTestCase. To test an Activity that is launched in a mode other thanstandard, you useSingleLaunchActivityTestCase.
ActivityInstrumentationTestCase2
The ActivityInstrumentationTestCase2 test case class is designed to do functional testing of one or more Activities in an application, using a normal system infrastructure. It runs the Activities in a normal instance of the application under test, using a standard system Context. It allows you to send mock Intents to the activity under test, so you can use it to test an activity that responds to multiple types of intents, or an activity that expects a certain type of data in the intent, or both. Notice, though, that it does not allow mock Contexts or Applications, so you can not isolate the test from the rest of a production system.
ActivityUnitTestCase
The ActivityUnitTestCase test case class tests a single activity in isolation. Before you start the activity, you can inject a mock Context or Application, or both. You use it to run activity tests in isolation, and to do unit testing of methods that do not interact with Android. You can not send mock Intents to the activity under test, although you can callActivity.startActivity(Intent) and then look at arguments that were received.
SingleLaunchActivityTestCase
The SingleLaunchActivityTestCase class is a convenience class for testing a single activity in an environment that doesn't change from test to test. It invokessetUp() andtearDown() only once, instead of once per method call. It does not allow you to inject any mock objects.
This test case is useful for testing an activity that runs in a mode other thanstandard. It ensures that the test fixture is not reset between tests. You can then test that the activity handles multiple calls correctly.
Mock objects and activity testing
This section contains notes about the use of the mock objects defined inandroid.test.mock with activity tests.
The mock object MockApplication is only available for activity testing if you use theActivityUnitTestCase test case class. By default,ActivityUnitTestCase, creates a hiddenMockApplication object that is used as the application under test. You can inject your own object usingsetApplication().
Assertions for activity testing
ViewAsserts defines assertions for Views. You use it to verify the alignment and position of View objects, and to look at the state of ViewGroup objects.
What To Test
· Input validation: Test that an activity responds correctly to input values in an EditText View. Set up a keystroke sequence, send it to the activity, and then usefindViewById(int) to examine the state of the View. You can verify that a valid keystroke sequence enables an OK button, while an invalid one leaves the button disabled. You can also verify that the Activity responds to invalid input by setting error messages in the View.
· Lifecycle events: Test that each of your application's activities handles lifecycle events correctly. In general, lifecycle events are actions, either from the system or from the user, that trigger a callback method such as onCreate() oronClick(). For example, an activity should respond to pause or destroy events by saving its state. Remember that even a change in screen orientation causes the current activity to be destroyed, so you should test that accidental device movements don't accidentally lose the application state.
· Intents: Test that each activity correctly handles the intents listed in the intent filter specified in its manifest. You can useActivityInstrumentationTestCase2 to send mock Intents to the activity under test.
· Runtime configuration changes: Test that each activity responds correctly to the possible changes in the device's configuration while your application is running. These include a change to the device's orientation, a change to the current language, and so forth. Handling these changes is described in detail in the topicHandling Runtime Changes.
· Screen sizes and resolutions: Before you publish your application, make sure to test it on all of the screen sizes and densities on which you want it to run. You can test the application on multiple sizes and densities using AVDs, or you can test your application directly on the devices that you are targeting. For more information, see the topicSupporting Multiple Screens.
Next Steps
To learn how to set up and run tests in Eclipse, please refer toTesting in Eclipse, with ADT. If you're not working in Eclipse, refer toTesting in Other IDEs.
If you want a step-by-step introduction to testing activities, try one of the testing tutorials:
· TheHello, Testing tutorial introduces basic testing concepts and procedures in the context of the Hello, World application.
· TheActivity Testing tutorial is an excellent follow-up to the Hello, Testing tutorial. It guides you through a more complex testing scenario that you develop against a more realistic activity-oriented application.
Appendix: UI Testing Notes
The following sections have tips for testing the UI of your Android application, specifically to help you handle actions that run in the UI thread, touch screen and keyboard events, and home screen unlock during testing.
Testing on the UI thread
An application's activities run on the application'sUI thread. Once the UI is instantiated, for example in the activity'sonCreate() method, then all interactions with the UI must run in the UI thread. When you run the application normally, it has access to the thread and does not have to do anything special.
This changes when you run tests against the application. With instrumentation-based classes, you can invoke methods against the UI of the application under test. The other test classes don't allow this. To run an entire test method on the UI thread, you can annotate the thread with @UIThreadTest. Notice that this will runall of the method statements on the UI thread. Methods that do not interact with the UI are not allowed; for example, you can't invokeInstrumentation.waitForIdleSync().
To run a subset of a test method on the UI thread, create an anonymous class of typeRunnable, put the statements you want in therun() method, and instantiate a new instance of the class as a parameter to the methodappActivity.runOnUiThread(), whereappActivity is the instance of the application you are testing.
For example, this code instantiates an activity to test, requests focus (a UI action) for the Spinner displayed by the activity, and then sends a key to it. Notice that the calls towaitForIdleSync andsendKeys aren't allowed to run on the UI thread:
private MyActivity mActivity; // MyActivity is the class name of the app under test private Spinner mSpinner; ... protected void setUp() throws Exception { super.setUp(); mInstrumentation = getInstrumentation(); mActivity = getActivity(); // get a references to the app under test /* * Get a reference to the main widget of the app under test, a Spinner */ mSpinner = (Spinner) mActivity.findViewById(com.android.demo.myactivity.R.id.Spinner01); ... public void aTest() { /* * request focus for the Spinner, so that the test can send key events to it * This request must be run on the UI thread. To do this, use the runOnUiThread method * and pass it a Runnable that contains a call to requestFocus on the Spinner. */ mActivity.runOnUiThread(new Runnable() { public void run() { mSpinner.requestFocus(); } }); mInstrumentation.waitForIdleSync(); this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);Turning off touch mode
To control the emulator or a device with key events you send from your tests, you must turn off touch mode. If you do not do this, the key events are ignored.
To turn off touch mode, you invoke ActivityInstrumentationTestCase2.setActivityTouchMode(false)before you callgetActivity() to start the activity. You must invoke the method in a test method that isnot running on the UI thread. For this reason, you can't invoke the touch mode method from a test method that is annotated with@UIThread. Instead, invoke the touch mode method fromsetUp().
Unlocking the emulator or device
You may find that UI tests don't work if the emulator's or device's home screen is disabled with the keyguard pattern. This is because the application under test can't receive key events sent bysendKeys(). The best way to avoid this is to start your emulator or device first and then disable the keyguard for the home screen.
You can also explicitly disable the keyguard. To do this, you need to add a permission in the manifest file (AndroidManifest.xml) and then disable the keyguard in your application under test. Note, though, that you either have to remove this before you publish your application, or you have to disable it with code in the published application.
To add the the permission, add the element <uses-permission android:name="android.permission.DISABLE_KEYGUARD"/> as a child of the<manifest> element. To disable the KeyGuard, add the following code to theonCreate() method of activities you intend to test:
mKeyGuardManager = (KeyguardManager) getSystemService(KEYGUARD_SERVICE); mLock = mKeyGuardManager.newKeyguardLock("activity_classname"); mLock.disableKeyguard();where activity_classname is the class name of the activity.
Troubleshooting UI tests
This section lists some of the common test failures you may encounter in UI testing, and their causes:
WrongThreadException
Problem:
For a failed test, the Failure Trace contains the following error message:android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
Probable Cause:
This error is common if you tried to send UI events to the UI thread from outside the UI thread. This commonly happens if you send UI events from the test application, but you don't use the@UIThread annotation or therunOnUiThread() method. The test method tried to interact with the UI outside the UI thread.
Suggested Resolution:
Run the interaction on the UI thread. Use a test class that provides instrumentation. See the previous sectionTesting on the UI Thread for more details.
java.lang.RuntimeException
Problem:
For a failed test, the Failure Trace contains the following error message:java.lang.RuntimeException: This method can not be called from the main application thread
Probable Cause:
This error is common if your test method is annotated with@UiThreadTest but then tries to do something outside the UI thread or tries to invokerunOnUiThread().
Suggested Resolution:
Remove the @UiThreadTest annotation, remove therunOnUiThread() call, or re-factor your tests.
%android-sdk%docs\resources\tutorials\testing\helloandroid_test.html
http://developer.android.com\resources\tutorials\testing\helloandroid_test.html
Tutorials:
Hello, Testing
In this document
1. Creating the Test Project
2. Creating the Test Case Class
1. Adding the test case class file
2. Adding the test case constructor
3. Adding a setup method
4. Adding a preconditions test
5. Adding a unit test
6. The finished test case class
3. Running the Tests and Seeing the Results
4. Next Steps
Related Tutorials
1. Hello, World
2. Activity Testing
See Also
1. Testing Android Applications
2. ActivityInstrumentationTestCase2
3. InstrumentationTestRunner
Android offers a powerful but easy-to-use testing framework that is well integrated with the SDK tools. Because writing tests is an important part of any development effort, this tutorial introduces the basics of testing and helps you get started testing quickly. To keep things simple, this tutorial builds on theHello World tutorial, which you may have already completed. It guides you through the process of setting up a test project, adding a test, and running the test against the Hello World application, all from inside the Eclipse environment. Of course, when you are done with this tutorial, you will want to create a test project for your own app and add various types of tests to it.
If you'd like to read an overview of the test and instrumentation framework and the core test case classes available, look at theTesting Android Applications topic. If you prefer a more advanced testing tutorial, try theActivity Testing tutorial.
Prerequisites
This tutorial and its code depend on the Hello World tutorial. If you haven't completed that tutorial already, do so now. You will learn the fundamentals of Android application development, and you will have an Android application that is ready to be tested. The tutorial guides you through the setup of an Android test project using the ADT Plugin for Eclipse and other SDK tools. You will need an SDK development platform that is version 1.5 (API level 3) or higher.
If you aren't developing in Eclipse with ADT or you would like to run tests directly from the command line, please see the topicTesting in Other IDEs for instructions.
Creating the Test Project
In the Hello World tutorial you created Android application project called HelloAndroid. A test of an Android application is also an Android application, and you create it within an Eclipse project. The Eclipse with ADTNew Android Test Project dialog creates a new test project and the framework of a new test application at the same time.
To create the test project and test application framework in Eclipse with ADT, follow these steps
1. In Eclipse, selectNew >Project >Android >Android Test Project.
The New Android Test Project dialog appears.
2. Set the following values:
o Test Project Name: "HelloAndroidTest"
o Test Target: Set "An existing Android project", click Browse, and then select "HelloAndroid" from the list of projects.
o Build Target: Set a target whose platform is Android 1.5 or above.
o Application name: "HelloAndroidTest"
o Package name: "com.example.helloandroid.test"
The dialog should now look like this:
3. Click Finish. The new project appears in the Package Explorer.
Creating the Test Case Class
You now have a test project HelloAndroidTest, and the basic structure of a test application also called HelloAndroidTest. The basic structure includes all the files and directories you need to build and run a test application,except for the class that contains your tests (the test case class).
The next step is to define the test case class. In this tutorial, you define a test case class that extends one of Android's test case classes designed for Activities. The class contains definitions for four methods:
1. HelloAndroidTest: This defines the constructor for the class. It is required by the Android testing framework.
2. setUp(): This overrides the JUnitsetUp() method. You use it to initialize the environment before each test runs.
3. testPreconditions(): This defines a small test that ensures the Hello, Android application starts up correctly.
4. testText(): This tests that what is displayed on the screen is the same as what is contained in the application's string resources. It is an example of a real unit test you would perform against an application's UI.
The following sections contain the code for the test case class and its methods.
Adding the test case class file
To add the Java file for the test case class, follow these steps
1. In Eclipse, open the HelloAndroidTest project if it is not already open.
2. Within HelloAndroidTest, expand thesrc/ folder and then find the package icon forcom.example.helloandroid.test. Right-click on the package icon and selectNew > Class:
The New Java Class dialog appears.
3. In the dialog, enter the following:
o Name: "HelloAndroidTest". This becomes the name of your test class.
o Superclass: "android.test.ActivityInstrumentationTestCase2<HelloAndroid>". The superclass is parameterized by an Activity class name.
The dialog should now look like this:
4. Do not change any of the other settings. Click Finish.
5. You now have a new fileHelloAndroidTest.java in the project. This file contains the classHelloAndroidTest, which extends the Activity test case classActivityInstrumentationTestCase2<T>. You parameterize the class withHelloAndroid, which is the class name of the activity under test.
6. OpenHelloAndroidTest.java. It should look like this:
7. package com.example.helloandroid.test;
8.
9. import android.test.ActivityInstrumentationTestCase2;
10.
11.public class HelloAndroidTest extends ActivityInstrumentationTestCase2<HelloAndroid> {
12.}
13. The test case class depends on theHelloAndroid class, which is not yet imported. To import the class, add the following line just before the currentimport statement:
14.import com.example.helloandroid.HelloAndroid;
Adding the test case constructor
The test case class constructor is used by the Android testing framework when you run the test. It calls the super constructor with parameters that tell the framework what Android application should be tested.
Add the following constructor method immediately after the class definition:
public HelloAndroidTest() { super("com.example.helloandroid", HelloAndroid.class); }Save the file HelloAndroidTest.java.
Adding a setup method
The setUp() method overrides the JUnitsetUp() method, which the Android testing framework calls prior to running each test method. You usesetUp() to initialize variables and prepare the test environment. For this test case, thesetUp() method starts the Hello, Android application, retrieves the text being displayed on the screen, and retrieves the text string in the resource file.
First, add the following code immediately after the constructor method:
@Override protected void setUp() throws Exception { super.setUp(); mActivity = this.getActivity(); mView = (TextView) mActivity.findViewById(com.example.helloandroid.R.id.textview); resourceString = mActivity.getString(com.example.helloandroid.R.string.hello); }For this code to work, you must also add some class members and another import statement. To add the class members, add the following code immediately after the class definition:
private HelloAndroid mActivity; private TextView mView; private String resourceString;To add the import statement, add the following statement just after the import forandroid.test.ActivityInstrumentationTestCase2:
import android.widget.TextView;Adding a preconditions test
A preconditions test checks the initial application conditions prior to executing other tests. It's similar tosetUp(), but with less overhead, since it only runs once.
Although a preconditions test can check for a variety of different conditions, in this application it only needs to check whether the application under test is initialized properly and the target TextView exists. To do this, it calls the inherited assertNotNull() method, passing a reference to the TextView. The test succeeds only if the object reference is not null.
public void testPreconditions() { assertNotNull(mView); }Adding a unit test
Now add a simple unit test to the test case class. The methodtestText() will call aJUnit Assert method to check whether the target TextView is displaying the expected text.
For this example, the test expects that the TextView is displaying the string resource that was originally declared for it in HelloAndroid'smain.xml file, referred to by the resource IDhello. The call toassertEquals(String,String) compares the expected value, read directly from the hellostring resource, to the text displayed by the TextView, obtained from the TextView'sgetText() method. The test succeeds only if the strings match.
To add this test, add the following code immediately after thetestPreconditions() method:
public void testText() { assertEquals(resourceString,(String)mView.getText()); }The finished test case class
You have now finished writing the test. This is what the complete test case class should look like:
package com.example.helloandroid.test; import com.example.helloandroid.HelloAndroid;import android.test.ActivityInstrumentationTestCase2;import android.widget.TextView; public class HelloAndroidTest extends ActivityInstrumentationTestCase2<HelloAndroid> { private HelloAndroid mActivity; // the activity under test private TextView mView; // the activity's TextView (the only view) private String resourceString; public HelloAndroidTest() { super("com.example.helloandroid", HelloAndroid.class); } @Override protected void setUp() throws Exception { super.setUp(); mActivity = this.getActivity(); mView = (TextView) mActivity.findViewById(com.example.helloandroid.R.id.textview); resourceString = mActivity.getString(com.example.helloandroid.R.string.hello); } public void testPreconditions() { assertNotNull(mView); } public void testText() { assertEquals(resourceString,(String)mView.getText()); }}Running the Tests and Seeing the Results
You can now run the tests you've created against the Hello, Android application. In Eclipse with ADT, you run a test application as anAndroid JUnit test rather than a regular Android application.
To run the test application as an Android JUnit test, in the Package Explorer right-click the HelloAndroidTest project and selectRun As >Android JUnit Test
The ADT plugin then launches the test application and the application under test on a the target emulator or device. When both applications are running, the testing framework runs the tests and reports the results in the JUnit view of Eclipse, which appears by default as a tab next to the Package Explorer.
As shown below, the JUnit view shows test results in two separate panes: an upper pane summarizes the tests that were run and a lower pane reports the failure traces for the tests. In this case, the tests in this example have run successfully, so there is no failure reported in the view:
The upper pane summarizes the test:
· "Finished afterx seconds": How long the test took to run.
· "Runs": The number of tests run.
· "Errors:": The number of program errors and exceptions encountered during the test run.
· "Failures:": The number of assertion failures encountered during the test run.
· A progress bar. The progress bar extends from left to right as the tests run.
If all the tests succeed, the bar remains green. If a test fails, the bar turns from green to red.
· A test method summary. Below the bar, you see a line for each class in the test application, labeled by its fully-qualified class name. To look at the results for the individual methods in a test case class, click the arrow at the left of the class to expand the line. You see the name of each test method. To the right of the method name, you see the time needed to run that method. You can look at the method's code by double-clicking its name.
The lower pane contains the failure trace. If all the tests are successful, this pane is empty. If some tests fail, then if you select a failed test in the upper pane, the lower view contains a stack trace for the test.
Next Steps
This simple example test application has shown you how to create a test project, create a test class and test cases, and then run the tests against a target application. Now that you are familiar with these fundamentals, here are some suggested next steps:
Learn more about testing on Android
· TheTesting Android Applications document in theDev Guide provides an overview of how testing on Android works. If you are just getting started with Android testing, reading that document will help you understand the tools available to you, so that you can develop effective tests.
Learn more about the testing classes available in Android
· For an overview of the types of testing classes you can use, browse through the reference documentation forActivityInstrumentationTestCase2,ProviderTestCase2,ServiceTestCase, andAssert.
Explore the Android instrumentation framework
· TheInstrumentationTestRunner class contains the code that Android uses to run tests against an application. TheInstrumentationTestCase class is the base class for test case classes that use additional instrumentation features.
Follow the Activity Testing tutorial
· TheActivity Testing tutorial is an excellent follow-up to this tutorial. It guides you through a more complex testing scenario that you develop against a more realistic application.
Tutorials:
Activity Testing
In this document
1. Prerequisites
2. Installing the Tutorial Sample Code
3. Setting Up the Emulator
4. Setting Up the Projects
5. Creating the Test Case Class
1. Adding the test case class file
2. Adding the test case constructor
3. Adding the setup method
4. Adding an initial conditions test
5. Adding a UI test
6. Adding state management tests
6. Running the Tests and Seeing the Results
7. Forcing Some Tests to Fail
8. Next Steps
Appendix
1. Installing the Completed Test Application Java File
2. For Users Not Developing In Eclipse
Related Tutorials
1. Hello, Testing
See Also
1. Testing Android Applications
2. ActivityInstrumentationTestCase2
3. Assert
4. InstrumentationTestRunner
Android includes powerful tools for testing applications. The tools extend JUnit with additional features, provide convenience classes for mock Android system objects, and use instrumentation to give you control over your main application while you are testing it. The entire Android testing environment is discussed in the documentTesting Android Applications.
This tutorial demonstrates the Android testing tools by presenting a simple Android application and then leading you step-by-step through the creation of a test application for it. 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 itsAndroidManifest.xml file.
· 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 JUnitTestCase class.
· 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.
· You choose an Android test case class based on the type of component (application, activity, content provider, or service) you are testing.
· Additional test tools in Eclipse/ADT provide integrated support for creating test applications, running them, and viewing the results.
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'sonCreate() method. Testing initial conditions also provides a confidence measure for subsequent tests.
· 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.
· 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.
Prerequisites
The instructions and code in this tutorial depend on the following:
· Basic knowledge of Android programming. If you haven't yet written an Android application, do theHello, World tutorial. If you want to learn more about Spinner, the application under test, then you might want to visit theHello Views > Spinner example.
· Some familiarity with the Android testing framework and concepts. If you haven't explored Android testing yet, start by reading the Developer Guide topicTesting Android Applications or following theHello, Testing tutorial.
· Eclipse with ADT. This tutorial describes how to set up and run a test application using Eclipse with ADT. If you haven't yet installed Eclipse and the ADT plugin, follow the steps in Installing the SDK to install them before continuing. If you are not developing in Eclipse, you will find instructions for setting up and running the test application in theappendix of this document.
· Android 1.5 platform (API Level 3) or higher. You must have the Android 1.5 platform (API Level 3) or higher installed in your SDK, because this tutorial uses APIs that were introduced in that version.
If you are not sure which platforms are installed in your SDK, open the Android SDK and AVD Manager and check in theInstalled Packages panel. If aren't sure how to download a platform into your SDK, readAdding SDK Components.
Installing the Tutorial Sample Code
During this tutorial, you will be working with sample code that is provided as part of the downloadable Samples component of the SDK. Specifically, you will be working with a pair of related sample applications — an application under test and a test application:
· Spinner is the application under test. This tutorial focuses on the common situation of writing tests for an application that already exists, so the main application is provided to you.
· SpinnerTest is the test application. In the tutorial, you create this application step-by-step. If you want to run quickly through the tutorial, you can install the completed SpinnerTest application first, and then follow the text. You may get more from the tutorial, however, if you create the test application as you go. The instructions for installing the completed test application are in the sectionInstalling the Completed Test Application Java File.
The sample applications are provided in the SDK component named "Samples for SDK API 8" and in later versions of the Samples.
To get started with the tutorial, first use the Android SDK and AVD manager to install an appropriate version of the Samples:
1. In Eclipse, selectWindow >Android SDK and AVD Manager.
2. Open theInstalled Packages panel and check whether "Samples for SDK API 8" (or higher version) is listed. If so, skip to the next section,Setting Up the Projects, to get started with the tutorial. Otherwise, continue with the next step.
3. Open theAvailable Packages panel.
4. Select the "Samples for SDK API 8" component and clickInstall Selected.
5. Verify and accept the component and then clickInstall Accepted. The Samples component will now be installed into your SDK.
When the installation is complete, the applications in the Samples component are stored at this location on your computer:
<sdk>/samples/android-8/
For general information about the Samples, see Getting the Samples
Note: Although the sample code for this tutorial is provided in the "Samples for SDK API 8" component, that does not imply that you need to build or run the application against the corresponding platform (Android 2.2). The API level referenced in the Samples component name indicates only the origin branch from which the samples were built.
Setting Up the Emulator
In this tutorial, you will use the Android emulator to run applications. The emulator needs an Android Virtual Device (AVD) with an API level equal to or higher than the one you set for the projects in the previous step. To find out how to check this and create the right AVD if necessary, see Creating an AVD.
As a test of the AVD and emulator, run the SpinnerActivity application in Eclipse with ADT. When it starts, click the large downward-pointing arrow to the right of the spinner text. You see the spinner expand and display the title "Select a planet" at the top. Click one of the other planets. The spinner closes, and your selection appears below it on the screen.
Setting Up the Projects
When you are ready to get started with the tutorial, begin by setting up Eclipse projects for both Spinner (the application under test) and SpinnerTest (the test application).
You'll be using the Spinner application as-is, without modification, so you'll be loading it into Eclipse as a new Android project from existing source. In the process, you'll be creating a new test project associated with Spinner that will contain the SpinnerTest application. The SpinnerTest application will be completely new and you'll be using the code examples in this tutorial to add test classes and tests to it.
To install the Spinner app in a new Android project from existing source, following these steps:
1. In Eclipse, selectFile > New > Project > Android > Android Project, then click Next. TheNew Android Project dialog appears.
2. In theProject name text box, enter "SpinnerActivity". TheProperties area is filled in automatically.
3. In theContents area, set "Create project from existing source".
4. ForLocation, clickBrowse, navigate to the directory<SDK_path>/samples/android-8/Spinner, then click Open. The directory name<SDK_path>/samples/android-8/Spinner now appears in theLocation text box.
5. In theBuild Target area, set a API level of 3 or higher. If you are already developing with a particular target, and it is API level 3 or higher, then use that target.
6. In theProperties area, in theMin SDK Version:, enter "3".
7. You should now see these values:
o Project Name: "SpinnerActivity"
o Create project from existing source: set
o Location: "<SDK_path>/samples/android-8/Spinner"
o Build Target: "API level of 3 or higher" (Target Name "Android 1.5 or higher")
o Package name: (disabled, set to "com.android.example.spinner")
o Create Activity: (disabled, set to ".SpinnerActivity")
o Min SDK Version: "3"
The following screenshot summarizes these values:
To create a new test project for the SpinnerTest application, follow these steps:
1. Click Next. TheNew Android Test Project dialog appears.
2. Set "Create a Test Project".
3. Leave the other values unchanged. The result should be:
o Create a Test Project: checked
o Test Project Name: "SpinnerActivityTest"
o Use default location: checked (this should contain the directory name "workspace/SpinnerActivityTest").
o Build Target: Use the same API level you used in the previous step.
o Application name: "SpinnerActivityTest"
o Package name: "com.android.example.spinner.test"
o Min SDK Version: "3"
The following screenshot summarizes these values:
4. Click Finish. Entries for SpinnerActivity and SpinnerActivityTest should appear in thePackage Explorer.
Note: If you setBuild Target to an API level higher than "3", you will see the warning "The API level for the selected SDK target does not match the Min SDK version". You do not need to change the API level or the Min SDK version. The message tells you that you are building the projects with one particular API level, but specifying that a lower API level is required. This may occur if you have chosen not to install the optional earlier API levels.
If you see errors listed in the Problems pane at the bottom of the Eclipse window, or if a red error marker appears next to the entry for SpinnerActivity in the Package Explorer, highlight the SpinnerActivity entry and then select Project > Clean. This should fix any errors.
You now have the application under test in the SpinnerActivity project, and an empty test project in SpinnerActivityTest. You may notice that the two projects are in different directories, but Eclipse with ADT handles this automatically. You should have no problem in either building or running them.
Notice that Eclipse and ADT have already done some initial setup for your test application. Expand the SpinnerActivityTest project, and notice that it already has an Android manifest fileAndroidManifest.xml. Eclipse with ADT created this when you added the test project. Also, the test application is already set up to use instrumentation. You can see this by examiningAndroidManifest.xml. Open it, then at the bottom of the center pane clickAndroidManifest.xml to display the XML contents:
<?xml version="1.0" encoding="utf-8"?><manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.example.spinner.test" android:versionCode="1" android:versionName="1.0"> <uses-sdk android:minSdkVersion="3" /> <instrumentation android:targetPackage="com.android.example.spinner" android:name="android.test.InstrumentationTestRunner" /> <application android:icon="@drawable/icon" android:label="@string/app_name"> <uses-library android:name="android.test.runner" /> ... </application></manifest>Notice the <instrumentation> element. The attributeandroid:targetPackage="com.android.example.spinner" tells Android that the application under test is defined in the Android packagecom.android.example.spinner. Android now knows to use that package'sAndroidManifest.xml file to launch the application under test. The<instrumentation> element also contains the attributeandroid:name="android.test.InstrumentationTestRunner", which tells Android instrumentation to run the test application with Android's instrumentation-enabled test runner.
Creating the Test Case Class
You now have a test project SpinnerActivityTest, and the basic structure of a test application also called SpinnerActivityTest. The basic structure includes all the files and directories you need to build and run a test application, except for the class that contains your tests (the test case class).
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 JUnitsetUp() method demonstrates some of the tasks you might perform before running an Android test.
· 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 usingsetUp(). The JUnitsetUp() 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.
· 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 theSpinnerActivity application uses them. The test shows the techniques for verifying that they work.
Android tests are contained in a special type of Android application that contains one or more test class definitions. Each of these contains one or more test methods that do the actual tests. In this tutorial, you will first add a test case class, and then add tests to it.
You first choose an Android test case class to extend. You choose from the base test case classes according to the Android component you are testing and the types of tests you are doing. In this tutorial, the application under test has a single simple activity, so the test case class will be for an Activity component. Android offers several, but the one that tests in the most realistic environment isActivityInstrumentationTestCase2, so you will use it as the base class. Like all activity test case classes, ActivityInstrumentationTestCase2 offers convenience methods for interacting directly with the UI of the application under test.
Adding the test case class file
To add ActivityInstrumentationTestCase2 as the base test case class, follow these steps:
1. In the Package Explorer, expand the test project SpinnerActivityTest if it is not open already.
2. Within SpinnerActivityTest, expand thesrc/ folder and then the package marker forcom.android.example.spinner.test. Right-click on the package name and selectNew > Class:
The New Java Class wizard appears:
3. In the wizard, enter the following:
o Name: "SpinnerActivityTest". This becomes the name of your test class.
o Superclass: "android.test.ActivityInstrumentationTestCase2<SpinnerActivity>". The superclass is parameterized, so you have to provide it your main application's class name.
Do not change any of the other settings. Click Finish.
4. You now have a new fileSpinnerActivityTest.java in the project.
5. To resolve the reference to SpinnerActivity, add the following import:
6. import com.android.example.spinner.SpinnerActivity;
Adding the test case constructor
To ensure that the test application is instantiated correctly, you must set up a constructor that the test runner will call when it instantiates your test class. This constructor has no parameters, and its sole purpose is to pass information to the superclass's default constructor. To set up this constructor, enter the following code in the class:
public SpinnerActivityTest() { super("com.android.example.spinner", SpinnerActivity.class); } // end of SpinnerActivityTest constructor definitionThis calls the superclass constructor with the Android package name (com.android.example.spinner)and main activity's class (SpinnerActivity.class) for the application under test. Android uses this information to find the application and activity to test.
You are now ready to add tests, by adding test methods to the class.
Adding the setup method
The setUp() method is invoked before every test. You use it to initialize variables and clean up from previous tests. You can also use the JUnit tearDown() method, which runsafter every test method. The tutorial does not use it.
The method you are going to add does the following:
· super.setUp(). Invokes the superclass constructor forsetUp(), which is required by JUnit.
· CallssetActivityInitialTouchMode(false). This turns offtouch mode in the device or emulator. If any of your test methods send key events to the application, you must turn off touch modebefore you start any activities; otherwise, the call is ignored.
· Stores references to system objects. Retrieves and stores a reference to the activity under test, theSpinner widget used by the activity, theSpinnerAdapter that backs the widget, and the string value of the selection that is set when the application is first installed. These objects are used in the state management test. The methods invoked are:
o getActivity(). Gets a reference to the activity under test (SpinnerActivity). This call also starts the activity if it is not already running.
o findViewById(int). Gets a reference to theSpinner widget of the application under test.
o 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 definitionAdd these members to the test case class:
private SpinnerActivity mActivity; private Spinner mSpinner; private SpinnerAdapter mPlanetData;Add these imports:
import android.widget.Spinner;import android.widget.SpinnerAdapter;You now have the the complete setUp() method.
Adding an initial conditions test
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 insetUp(), which the test runner calls automatically before every test. The verifications are done with JUnitAssert 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 definitionAdd this member:
public static final int ADAPTER_COUNT = 9;Adding a UI test
Now create a UI test that selects an item from theSpinner widget. The test sends key events to the UI with key events. The test confirms that the selection matches the result you expect.
This test demonstrates the power of using instrumentation in Android testing. Only an instrumentation-based test class allows you to send key events (or touch events) to the application under test. With instrumentation, you can test your UI without having to take screenshots, record the screen, or do human-controlled testing.
To work with the spinner, the test has to request focus for it and then set it to a known position. The test usesrequestFocus() andsetSelection() to do this. Both of these methods interact with a View in the application under test, so you have to call them in a special way.
Code in a test application that interacts with a View of the application under test must run in the main application's thread, also known as theUI thread. To do this, you use theActivity.runOnUiThread() method. You pass the code torunOnUiThread()in an anonymousRunnable object. To set the Java statements in theRunnable object, you override the object'srun() method.
To send key events to the UI of the application under test, you use thesendKeys() method. This method does not have to run on the UI thread, since Android uses instrumentation to pass the key events to the application under test.
The last part of the test compares the selection made by sending the key events to a pre-determined value. This tests that the spinner is working as intended.
The following sections show you how to add the code for this test.
1. Get focus and set selection. Create a new methodpublic void testSpinnerUI(). Add code to to request focus for the spinner and set its position to default or initial position, "Earth". This code is run on the UI thread of the application under test:
2. public void testSpinnerUI() {
3.
4. mActivity.runOnUiThread(
5. new Runnable() {
6. public void run() {
7. mSpinner.requestFocus();
8. mSpinner.setSelection(INITIAL_POSITION);
9. } // end of run() method definition
10. } // end of anonymous Runnable object instantiation
11. ); // end of invocation of runOnUiThread
Add the following member to the test case class.
public static final int INITIAL_POSITION = 0;
12. Make a selection. Send key events to the spinner to select one of the items. To do this, open the spinner by "clicking" the center keypad button (sending a DPAD_CENTER key event) and then clicking (sending) the down arrow keypad button five times. Finally, click the center keypad button again to highlight the desired item. Add the following code:
13. this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);
14. for (int i = 1; i <= TEST_POSITION; i++) {
15. this.sendKeys(KeyEvent.KEYCODE_DPAD_DOWN);
16. } // end of for loop
17.
18. this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);
Add the following member to the test case class:
public static final int TEST_POSITION = 5;
This sets the final position of the spinner to "Saturn" (the spinner's backing adapter is 0-based).
19. Check the result. Query the current state of the spinner, and compare its current selection to the expected value. Call the methodgetSelectedItemPosition() to find out the current selection position, and thengetItemAtPosition() to get the object corresponding to that position (casting it to a String). Assert that this string value matches the expected value of "Saturn":
20. mPos = mSpinner.getSelectedItemPosition();
21. mSelection = (String)mSpinner.getItemAtPosition(mPos);
22. TextView resultView =
23. (TextView) mActivity.findViewById(
24. com.android.example.spinner.R.id.SpinnerResult
25. );
26.
27. String resultText = (String) resultView.getText();
28.
29. assertEquals(resultText,mSelection);
30.
31. } // end of testSpinnerUI() method definition
Add the following members to the test case class:
private String mSelection;
private int mPos;
Add the following imports to the test case class:
import android.view.KeyEvent;
import android.widget.TextView;
Pause here to run the tests you have. The procedure for running a test application is different from running a regular Android application. You run a test application as an Android JUnit application. To see how to do this, seeRunning the Tests and Seeing the Results.
Eventually, you will see the SpinnerActivity application start, and the test application controlling it by sending it key events. You will also see a new JUnit view in the Explorer pane, showing the results of the test. The JUnit view is documented in a following section,Running the Test and Seeing the Results.
Adding state management tests
You now write two tests that verify that SpinnerActivity maintains its state when it is paused or terminated. The state, in this case, is the current selection in the spinner. When users make a selection, pause or terminate the application, and then resume or restart it, they should see the same selection.
Maintaining state is an important feature of an application. Users may switch from the current application temporarily to answer the phone, and then switch back. Android may decide to terminate and restart an activity to change the screen orientation, or terminate an unused activity to regain storage. In each case, users are best served by having the UI return to its previous state (except where the logic of the application dictates otherwise).
SpinnerActivity manages its state in these ways:
· Activity is hidden. When the spinner screen (the activity) is running but hidden by some other screen, it stores the spinner's position and value in a form that persists while the application is running.
· Application is terminated. When the activity is terminated, it stores the spinner's position and value in a permanent form. The activity can read the position and value when it restarts, and restore the spinner to its previous state.
· Activity re-appears. When the user returns to the spinner screen, the previous selection is restored.
· Application is restarted. When the user starts the application again, the previous selection is restored.
Note: An application can manage its state in other ways as well, but these are not covered in this tutorial.
When an activity is hidden, it is paused. When it re-appears, itresumes. Recognizing that these are key points in an activity's life cycle, the Activity class provides two callback methodsonPause() andonResume() for handling pauses and resumes. SpinnerActivity uses them for code that saves and restores state.
Note: If you would like to learn more about the difference between losing focus/pausing and killing an application, read about theactivity lifecycle.
The first test verifies that the spinner selection is maintained after the entire application is shut down and then restarted. The test uses instrumentation to set the spinner's variables outside of the UI. It then terminates the activity by calling Activity.finish(), and restarts it using the instrumentation methodgetActivity(). The test then asserts that the current spinner state matches the test values.
The second test verifies that the spinner selection is maintained after the activity is paused and then resumed. The test uses instrumentation to set the spinner's variables outside of the UI and then force calls to theonPause() andonResume() methods. The test then asserts that the current spinner state matches the test values.
Notice that these tests make limited assumptions about the mechanism by which the activity manages state. The tests use the activity's getters and setters to control the spinner. The first test also knows that hiding an activity calls onPause(), and bringing it back to the foreground callsonResume(). Other than this, the tests treat the activity as a "black box".
To add the code for testing state management across shutdown and restart, follow these steps:
1. Add the test methodtestStateDestroy(), then set the spinner selection to a test value:
2. public void testStateDestroy() {
3. mActivity.setSpinnerPosition(TEST_STATE_DESTROY_POSITION);
4. mActivity.setSpinnerSelection(TEST_STATE_DESTROY_SELECTION);
5. Terminate the activity and restart it:
6. mActivity.finish();
7. mActivity = this.getActivity();
8. Get the current spinner settings from the activity:
9. int currentPosition = mActivity.getSpinnerPosition();
10. String currentSelection = mActivity.getSpinnerSelection();
11. Test the current settings against the test values:
12. assertEquals(TEST_STATE_DESTROY_POSITION, currentPosition);
13. assertEquals(TEST_STATE_DESTROY_SELECTION, currentSelection);
14. } // end of testStateDestroy() method definition
Add the following members to the test case class:
public static final int TEST_STATE_DESTROY_POSITION = 2;
public static final String TEST_STATE_DESTROY_SELECTION = "Earth";
To add the code for testing state management across a pause and resume, follow these steps:
1. Add the test methodtestStatePause():
2. @UiThreadTest
3. public void testStatePause() {
The @UiThreadTest annotation tells Android to build this method so that it runs on the UI thread. This allows the method to change the state of the spinner widget in the application under test. This use of @UiThreadTest shows that, if necessary, you can run an entire method on the UI thread.
4. Set up instrumentation. Get the instrumentation object that is controlling the application under test. This is used later to invoke theonPause() andonResume() methods:
5. Instrumentation mInstr = this.getInstrumentation();
6. Set the spinner selection to a test value:
7. mActivity.setSpinnerPosition(TEST_STATE_PAUSE_POSITION);
8. mActivity.setSpinnerSelection(TEST_STATE_PAUSE_SELECTION);
9. Use instrumentation to call the Activity'sonPause():
10. mInstr.callActivityOnPause(mActivity);
Under test, the activity is waiting for input. The invocation ofcallActivityOnPause(android.app.Activity) performs a call directly to the activity'sonPause() instead of manipulating the activity's UI to force it into a paused state.
11. Force the spinner to a different selection:
12. mActivity.setSpinnerPosition(0);
13. mActivity.setSpinnerSelection("");
This ensures that resuming the activity actually restores the spinner's state rather than simply leaving it as it was.
14. Use instrumentation to call the Activity'sonResume():
15. mInstr.callActivityOnResume(mActivity);
Invoking callActivityOnResume(android.app.Activity) affects the activity in a way similar tocallActivityOnPause. The activity'sonResume() method is invoked instead of manipulating the activity's UI to force it to resume.
16. Get the current state of the spinner:
17. int currentPosition = mActivity.getSpinnerPosition();
18. String currentSelection = mActivity.getSpinnerSelection();
19. Test the current spinner state against the test values:
20. assertEquals(TEST_STATE_PAUSE_POSITION,currentPosition);
21. assertEquals(TEST_STATE_PAUSE_SELECTION,currentSelection);
22. } // end of testStatePause() method definition
Add the following members to the test case class:
public static final int TEST_STATE_PAUSE_POSITION = 4;
public static final String TEST_STATE_PAUSE_SELECTION = "Jupiter";
23. Add the following imports:
24. import android.app.Instrumentation;
25. import android.test.UiThreadTest;
Running the Tests and Seeing the Results
The most simple way to run the SpinnerActivityTest test case is to run it directly from the Package Explorer.
To run the SpinnerActivityTest test, follow these steps:
1. In the Package Explorer, right-click the project SpinnerActivityTest at the top level, and then selectRun As >Android JUnit Test:
2. You will see the emulator start. When the unlock option is displayed (its appearance depends on the API level you specified for the AVD), unlock the home screen.
3. The test application starts. You see a new tab for theJUnit view, next to the Package Explorer tab:
This view contains two sub-panes. The top pane summarizes the tests that were run, and the bottom pane shows failure traces for highlighted tests.
At the conclusion of a successful test run, this is the view's appearance:
The upper pane summarizes the test:
· Total time elapsed for the test application(labeledFinished after <x> seconds).
· Number of runs (Runs:) - the number of tests in the entire test class.
· Number of errors (Errors:) - the number of program errors and exceptions encountered during the test run.
· Number of failures (Failures:) - the number of test failures encountered during the test run. This is the number of assertion failures. A test can fail even if the program does not encounter an error.
· A progress bar. The progress bar extends from left to right as the tests run.
If all the tests succeed, the bar remains green. If a test fails, the bar turns from green to red.
· A test method summary. Below the bar, you see a line for each class in the test application. To look at the results for the individual methods in a test, click the arrow at the left to expand the line. You see the name of each test method. To the right of the name, you see the time taken by the test. You can look at the test's code by double-clicking its name.
The lower pane contains the failure trace. If all the tests are successful, this pane is empty. If some tests fail, then if you highlight a failed test in the upper pane, the lower view contains a stack trace for the test. This is demonstrated in the next section.
Note: If you run the test application and nothing seems to happen, look for the JUnit view. If you do not see it, you may have run the test application as a regular Android application. Remember that you need to run it as an Android JUnit application.
Forcing Some Tests to Fail
A test is as useful when it fails as when it succeeds. This section shows what happens in Eclipse with ADT when a test fails. You can quickly see that a test class has failed, find the method or methods that failed, and then use a failure trace to find the exact problem.
The example application SpinnerActivity that you downloaded passes all the tests in the test application SpinnerActivityTest. To force the test to fail, you must modify the example application. You change a line of setup code in the application under test. This causes the testPreConditions() andtestTextView() test methods to fail.
To force the tests to fail, follow these steps:
1. In Eclipse with ADT, go to the SpinnerActivity project and open the fileSpinnerActivity.java.
2. At the top ofSpinnerActivity.java, at the end of theonCreate() method, find the following line:
3. // mySpinner.setOnItemSelectedListener(null);
Remove the forward slash characters at the beginning of the line to uncomment the line. This sets the listener callback to null:
mySpinner.setOnItemSelectedListener(null);
4. ThetestPreConditions() method inSpinnerActivityTest contains the following test:assertTrue(mSpinner.getOnItemSelectedListener() != null);. This test asserts that the listener callback isnot null. Since you have modified the application under test, this assertion now fails.
5. Run the test, as described in the previous sectionRunning the Tests and Seeing the Results.
The JUnit view is either created or updated with the results of the test. Now, however, the progress bar is red, the number of failures is 2, and small "x" icons appear in the list icons next to the testPreConditions and TestSpinnerUI tests. This indicates that the tests have failed. The display is similar to this:
You now want to look at the failures to see exactly where they occurred.
To examine the failures, follow these steps:
1. Click the testPreconditions entry. In the lower pane entitledFailure Trace, you see a stack trace of the calls that led to the failure. This trace is similar to the following screenshot:
2. The first line of the trace tells you the error. In this case, a JUnit assertion failed. To look at the assertion in the test code, double-click the next line (the first line of the trace). In the center pane a new tabbed window opens, containing the code for the test applicationSpinnerActivityTest. The failed assertion is highlighted in the middle of the window.
The assertion failed because you modified the main application to set thegetOnItemSelectedListener callback tonull.
You can look at the failure in testTextView if you want. Remember, though, thattestPreConditions is meant to verify the initial setup of the application under test. If testPreConditions() fails, then succeeding tests can't be trusted. The best strategy to follow is to fix the problem and re-run all the tests.
Remember to go back to SpinnerActivity.java and re-comment the line you uncommented in an earlier step.
You have now completed the tutorial.
Next Steps
This example test application has shown you how to create a test project and link it to the application you want to test, how to choose and add a test case class, how to write UI and state management tests, and how to run the tests against the application under test. Now that you are familiar with the basics of testing Android applications, here are some suggested next steps:
Learn more about testing on Android
· If you haven't done so already, read theTesting Android Applications document in theDev Guide. It provides an overview of how testing on Android works. If you are just getting started with Android testing, reading that document will help you understand the tools available to you, so that you can develop effective tests.
Review the main Android test case classes
· ActivityInstrumentationTestCase2
· ActivityUnitTestCase
· ProviderTestCase2
· ServiceTestCase
Learn more about the assert and utility classes
· Assert, the JUnit Assert class.
· MoreAsserts, additional Android assert methods.
· ViewAsserts, useful assertion methods for testing Views.
· TouchUtils, utility methods for simulating touch events in an Activity.
Learn about instrumentation and the instrumented test runner
· Instrumentation, the base instrumentation class.
· InstrumentationTestCase, the base instrumentation test case.
· InstrumentationTestRunner, the standard Android test runner.
Appendix
Installing the Completed Test Application Java File
The recommended approach to this tutorial is to follow the instructions step-by-step and write the test code as you go. However, if you want to do this tutorial quickly, you can install the entire Java file for the test application into the test project.
To do this, you first create a test project with the necessary structure and files by using the automated tools in Eclipse. Then you exit Eclipse and copy the test application's Java file from the SpinnerTest sample project into your test project. The SpinnerTest sample project is part of the Samples component of the SDK.
The result is a complete test application, ready to run against the Spinner sample application.
To install the test application Java file, follow these steps:
1. Set up the projects for the application under test and the test application, as described in the section sectionSetting Up the Projects.
2. Set up the emulator, as described in the sectionSetting Up the Emulator.
3. Add the test case class, as described in the sectionAdding the test case class file.
4. Close Eclipse with ADT.
5. Copy the file<SDK_path>/samples/android-8/SpinnerTest/src/com/android/example/spinner/test/SpinnerActivityTest.java to the directoryworkspace/SpinnerActivityTest/src/com/android/example/spinner/test/.
6. Restart Eclipse with ADT.
7. In Eclipse with ADT, re-build the projectSpinnerActivityTest by selecting it in the Package Explorer, right-clicking, and selectingProject > Clean.
8. The complete, working test application should now be in theSpinnerActivityTest project.
You can now continue with the tutorial, starting at the sectionAdding the test case constructor and following along in the text.
For Users Not Developing In Eclipse
If you are not developing in Eclipse, you can still do this tutorial. Android provides tools for creating test applications using a code editor and command-line tools. You use the following tools:
· adb - Installs and uninstalls applications and test applications to a device or the emulator. You also use this tool to run the test application from the command line.
· android - Manages projects and test projects. This tool also manages AVDs and Android platforms.
You use the emulator tool to run the emulator from the command line.
Here are the general steps for doing this tutorial using an editor and the command line:
1. As described in the sectionInstalling the Tutorial Sample Code, get the sample code. You will then have a directory<SDK_path>/samples/android-8, containing (among others) the directoriesSpinner andSpinnerTest:
o Spinner contains the main application, also known as theapplication under test. This tutorial focuses on the common situation of writing tests for an application that already exists, so the main application is provided to you.
o SpinnerTest contains all the code for the test application. If you want to run quickly through the tutorial, you can install the test code and then follow the text. You may get more from the tutorial, however, if you write the code as you go. The instructions for installing the test code are in the sectionAppendix: Installing the Completed Test Application.
2. Navigate to the directory<SDK_path>/samples/android-8.
3. Create a new Android application project usingandroid create project:
4. $ android create project -t <APItarget> -k com.android.example.spinner -a SpinnerActivity -n SpinnerActivity -p Spinner
The value of <APItarget> should be "3" (API level 3) or higher. If you are already developing with a particular API level, and it is higher than 3, then use that API level.
This a new Android project SpinnerActivity in the existingSpinner directory. The existing source and resource files are not touched, but theandroid tool adds the necessary build files.
5. Create a new Android test project usingandroid create test-project:
6. $ android create test-project -m ../Spinner -n SpinnerActivityTest -p SpinnerActivityTest
This will create a new Android test project in thenew directorySpinnerActivityTest. You do this so that the solution to the tutorial that is inSpinnerTest is left untouched. If you want to use the solution code instead of entering it as you read through the tutorial, refer to the sectionAppendix: Installing the Completed Test Application.
Note: Runningandroid create test-project will automatically create the fileAndroidManifest.xml with the correct<instrumentation> element.
7. Build the sample application. If you are building with Ant, then it is easiest to use the commandant debug to build a debug version, since the SDK comes with a debug signing key. The result will be the fileSpinner/bin/SpinnerActivity-debug.apk. You can install this to your device or emulator. Attach your device or start the emulator if you haven't already, and run the command:
8. $ adb install Spinner/bin/SpinnerActivity-debug.apk
9. To create the test application, create a fileSpinnerActivityTest.java in the directorySpinnerActivityTest/src/com/android/example/spinner/test/.
10. Follow the tutorial, starting with the sectionCreating the Test Case Class. When you are prompted to run the sample application, go the the Launcher screen in your device or emulator and select SpinnerActivity. When you are prompted to run the test application, return here to continue with the following instructions.
11. Build the test application. If you are building with Ant, then it is easiest to use the commandant debug to build a debug version, since the SDK comes with a debug signing key. The result will be the Android fileSpinnerActivityTest/bin/SpinnerActivityTest-debug.apk. You can install this to your device or emulator. Attach your device or start the emulator if you haven't already, and run the command:
12.$ adb install SpinnerActivityTest/bin/SpinnerActivityTest-debug.apk
13. In your device or emulator, check that both the main applicationSpinnerActivity and the test applicationSpinnerActivityTest are installed.
14. To run the test application, enter the following at the command line:
15.$ adb shell am instrument -w com.android.example.spinner.test/android.test.InstrumentationTestRunner
The result of a successful test looks like this:
com.android.example.spinner.test.SpinnerActivityTest:....Test results for InstrumentationTestRunner=....Time: 10.098OK (4 tests)If you force the test to fail, as described in the previous sectionForcing Some Tests to Fail, then the output looks like this:
com.android.example.spinner.test.SpinnerActivityTest:Failure in testPreConditions:junit.framework.AssertionFailedError at com.android.example.spinner.test.SpinnerActivityTest.testPreConditions(SpinnerActivityTest.java:104) at java.lang.reflect.Method.invokeNative(Native Method) at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:205) at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:195) at android.test.ActivityInstrumentationTestCase2.runTest(ActivityInstrumentationTestCase2.java:175) at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169) at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154) at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:430) at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447)Failure in testSpinnerUI:junit.framework.ComparisonFailure: expected:<Result> but was:<Saturn> at com.android.example.spinner.test.SpinnerActivityTest.testSpinnerUI(SpinnerActivityTest.java:153) at java.lang.reflect.Method.invokeNative(Native Method) at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:205) at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:195) at android.test.ActivityInstrumentationTestCase2.runTest(ActivityInstrumentationTestCase2.java:175) at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169) at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154) at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:430) at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447)..Test results for InstrumentationTestRunner=.F.F..Time: 9.377FAILURES!!!Tests run: 4, Failures: 2, Errors: 0↑ Go to top
← Back to Tutorials
Testing:
Service Testing
In this document
1. Service Design and Testing
2. ServiceTestCase
3. Mock object classes
4. What to Test
Key Classes
1. InstrumentationTestRunner
2. ServiceTestCase
3. MockApplication
4. RenamingDelegatingContext
Related Tutorials
1. Hello, Testing
2. Activity Testing
See Also
1. Testing in Eclipse, with ADT
2. Testing in Other IDEs
Android provides a testing framework for Service objects that can run them in isolation and provides mock objects. The test case class for Service objects isServiceTestCase. Since the Service class assumes that it is separate from its clients, you can test a Service object without using instrumentation.
This document describes techniques for testing Service objects. If you aren't familiar with the Service class, please read theServices document. If you aren't familiar with Android testing, please readTesting Fundamentals, the introduction to the Android testing and instrumentation framework.
Service Design and Testing
When you design a Service, you should consider how your tests can examine the various states of the Service lifecycle. If the lifecycle methods that start up your Service, such asonCreate() oronStartCommand() do not normally set a global variable to indicate that they were successful, you may want to provide such a variable for testing purposes.
Most other testing is facilitated by the methods in theServiceTestCase test case class. For example, thegetService() method returns a handle to the Service under test, which you can test to confirm that the Service is running even at the end of your tests.
ServiceTestCase
ServiceTestCase extends the JUnitTestCase class with with methods for testing application permissions and for controlling the application and Service under test. It also provides mock application and Context objects that isolate your test from the rest of the system.
ServiceTestCase defers initialization of the test environment until you callServiceTestCase.startService() orServiceTestCase.bindService(). This allows you to set up your test environment, particularly your mock objects, before the Service is started.
Notice that the parameters to ServiceTestCase.bindService()are different from those forService.bindService(). For theServiceTestCase version, you only provide an Intent. Instead of returning a boolean,ServiceTestCase.bindService() returns an object that subclassesIBinder.
The setUp() method forServiceTestCase is called before each test. It sets up the test fixture by making a copy of the current system Context before any test methods touch it. You can retrieve this Context by callinggetSystemContext(). If you override this method, you must callsuper.setUp() as the first statement in the override.
The methods setApplication() andsetContext(Context) setContext()} allow you to set a mock Context or mock Application (or both) for the Service, before you start it. These mock objects are described inMock object classes.
By default, ServiceTestCase runs the test methodtestAndroidTestCaseSetupProperly(), which asserts that the base test case class successfully set up a Context before running.
Mock object classes
ServiceTestCase assumes that you will use a mock Context or mock Application (or both) for the test environment. These objects isolate the test environment from the rest of the system. If you don't provide your own instances of these objects before you start the Service, thenServiceTestCase will create its own internal instances and inject them into the Service. You can override this behavior by creating and injecting your own instances before starting the Service
To inject a mock Application object into the Service under test, first create a subclass ofMockApplication.MockApplication is a subclass ofApplication in which all the methods throw an Exception, so to use it effectively you subclass it and override the methods you need. You then inject it into the Service with thesetApplication() method. This mock object allows you to control the application values that the Service sees, and isolates it from the real system. In addition, any hidden dependencies your Service has on its application reveal themselves as exceptions when you run the test.
You inject a mock Context into the Service under test with thesetContext() method. The mock Context classes you can use are described in more detail in Testing Fundamentals.
What to Test
The topic What To Test lists general considerations for testing Android components. Here are some specific guidelines for testing a Service:
· Ensure that theonCreate() is called in response toContext.startService() orContext.bindService(). Similarly, you should ensure thatonDestroy() is called in response toContext.stopService(),Context.unbindService(),stopSelf(), orstopSelfResult().
· Test that your Service correctly handles multiple calls fromContext.startService(). Only the first call triggersService.onCreate(), but all calls trigger a call toService.onStartCommand().
In addition, remember that startService() calls don't nest, so a single call toContext.stopService() orService.stopSelf() (but notstopSelf(int)) will stop the Service. You should test that your Service stops at the correct point.
· Test any business logic that your Service implements. Business logic includes checking for invalid values, financial and arithmetic calculations, and so forth.
Testing:
Content Provider Testing
In this document
1. Content Provider Design and Testing
2. The Content Provider Testing API
1. ProviderTestCase2
2. Mock object classes
3. What To Test
4. Next Steps
Key Classes
1. InstrumentationTestRunner
2. ProviderTestCase2
3. IsolatedContext
4. MockContentResolver
See Also
1. Testing Fundamentals
2. Testing in Eclipse, with ADT
3. Testing in Other IDEs
Content providers, which store and retrieve data and make it accessible across applications, are a key part of the Android API. As an application developer you're allowed to provide your own public providers for use by other applications. If you do, then you should test them using the API you publish.
This document describes how to test public content providers, although the information is also applicable to providers that you keep private to your own application. If you aren't familiar with content providers or the Android testing framework, please read Content Providers, the guide to developing content providers, andTesting Fundamentals, the introduction to the Android testing and instrumentation framework.
Content Provider Design and Testing
In Android, content providers are viewed externally as data APIs that provide tables of data, with their internals hidden from view. A content provider may have many public constants, but it usually has few if any public methods and no public variables. This suggests that you should write your tests based only on the provider's public members. A content provider that is designed like this is offering a contract between itself and its users.
The base test case class for content providers, ProviderTestCase2, allows you to test your content provider in an isolated environment. Android mock objects such asIsolatedContext andMockContentResolver also help provide an isolated test environment.
As with other Android tests, provider test packages are run under the control of the test runnerInstrumentationTestRunner. The sectionRunning Tests With InstrumentationTestRunner describes the test runner in more detail. The topicTesting in Eclipse, with ADT shows you how to run a test package in Eclipse, and the topicTesting in Other IDEs shows you how to run a test package from the command line.
Content Provider Testing API
The main focus of the provider testing API is to provide an isolated testing environment. This ensures that tests always run against data dependencies set explicitly in the test case. It also prevents tests from modifying actual user data. For example, you want to avoid writing a test that fails because there was data left over from a previous test, and you want to avoid adding or deleting contact information in a actual provider.
The test case class and mock object classes for provider testing set up this isolated testing environment for you.
ProviderTestCase2
You test a provider with a subclass of ProviderTestCase2. This base class extendsAndroidTestCase, so it provides the JUnit testing framework as well as Android-specific methods for testing application permissions. The most important feature of this class is its initialization, which creates the isolated test environment.
The initialization is done in the constructor for ProviderTestCase2, which subclasses call in their own constructors. TheProviderTestCase2 constructor creates anIsolatedContext object that allows file and database operations but stubs out other interactions with the Android system. The file and database operations themselves take place in a directory that is local to the device or emulator and has a special prefix.
The constructor then creates a MockContentResolver to use as the resolver for the test. TheMockContentResolver class is described in detail in the sectionMock object classes.
Lastly, the constructor creates an instance of the provider under test. This is a normalContentProvider object, but it takes all of its environment information from theIsolatedContext, so it is restricted to working in the isolated test environment. All of the tests done in the test case class run against this isolated object.
Mock object classes
ProviderTestCase2 usesIsolatedContext andMockContentResolver, which are standard mock object classes. To learn more about them, please read Testing Fundamentals.
What To Test
The topic What To Test lists general considerations for testing Android components. Here are some specific guidelines for testing content providers.
· Test with resolver methods: Even though you can instantiate a provider object inProviderTestCase2, you should always test with a resolver object using the appropriate URI. This ensures that you are testing the provider using the same interaction that a regular application would use.
· Test a public provider as a contract: If you intent your provider to be public and available to other applications, you should test it as a contract. This includes the following ideas:
o Test with constants that your provider publicly exposes. For example, look for constants that refer to column names in one of the provider's data tables. These should always be constants publicly defined by the provider.
o Test all the URIs offered by your provider. Your provider may offer several URIs, each one referring to a different aspect of the data. TheNote Pad sample, for example, features a provider that offers one URI for retrieving a list of notes, another for retrieving an individual note by it's database ID, and a third for displaying notes in a live folder.
o Test invalid URIs: Your unit tests should deliberately call the provider with an invalid URI, and look for errors. Good provider design is to throw an IllegalArgumentException for invalid URIs.
· Test the standard provider interactions: Most providers offer six access methods: query, insert, delete, update, getType, and onCreate(). Your tests should verify that all of these methods work. These are described in more detail in the topic Content Providers.
· Test business logic: Don't forget to test the business logic that your provider should enforce. Business logic includes handling of invalid values, financial or arithmetic calculations, elimination or combining of duplicates, and so forth. A content provider does not have to have business logic, because it may be implemented by activities that modify the data. If the provider does implement business logic, you should test it.
Next Steps
To learn how to set up and run tests in Eclipse, please refer toTesting in Eclipse, with ADT. If you're not working in Eclipse, refer toTesting in Other IDEs.
If you want a step-by-step introduction to testing activities, try one of the testing tutorials:
· TheHello, Testing tutorial introduces basic testing concepts and procedures in the context of the Hello, World application.
· TheActivity Testing tutorial is an excellent follow-up to the Hello, Testing tutorial. It guides you through a more complex testing scenario that you develop against a more realistic activity-oriented application.
参考链接：http://blog.csdn.net/superkris/article/details/7967145
- android自动化测试之Junit
- android自动化测试1-Junit
- Android之JUnit测试
- android jUnit test 进行自动化测试
- Android下白盒自动化回归测试junit
- ANT+JUnit自动化测试
- 自动化测试(JUnit)
- junit+selenium自动化测试
- selenium+Junit自动化测试
- 《android自动化测试之NativerDriver 一 集成junit以及脚本的使用》
- [自动化测试] Junit+webdrive 实现android手机测试
- android学习之-Junit测试
- Android基础之----junit测试
- Android开发之Junit测试
- Android之Junit测试类
- Java单元测试进阶之单元测试利器JUnit（测试自动化）
- Android自动化测试(Jenkins+Robotium+Ant+Junit)[PART one]
- Android自动化测试(Jenkins+Robotium+Ant+Junit)[PART TWO]
- android自动化测试之CTS
- 用动态语言编写程序，命名更重要
- UNIX网络编程
- 如何使用 base 标签使页面中的所有标签在新窗口中打开
- bc --- 计算器命令
- android自动化测试之Junit
- JProfiler8 注册码序列号
- XML 从入门到精通（一）XML基础
- UISwitch 开关控件 开发笔记
- HashMap是无序的
- 面向对象__阶段总结__【覆盖与重载的区别】【继承，多态的一些细节】
- 重定向用户
- libc、glibc和glib的关系
- ORA-01008:并非所有的变量都已绑定
