Android Activity 测试
来源:互联网 发布:电话爆破软件 编辑:程序博客网 时间:2024/04/27 17:15
Activity Testing
In this document
- The Activity Testing API
- ActivityInstrumentationTestCase2
- ActivityUnitTestCase
- SingleLaunchActivityTestCase
- Mock objects and activity testing
- Assertions for activity testing
- What to Test
- Next Steps
- Appendix: UI Testing Notes
- Testing on the UI thread
- Turning off touch mode
- Unlocking the Emulator or Device
- Troubleshooting UI tests
Key Classes
InstrumentationTestRunner
ActivityInstrumentationTestCase2
ActivityUnitTestCase
Related Tutorials
- Hello, Testing
- Activity Testing
See Also
- Testing in Eclipse, with ADT
- Testing in Other IDEs
Activity testing is particularly dependent on the the Android instrumentation framework. Unlike other components, activities have a complex lifecycle based on callback methods; these can't be invoked directly except by instrumentation. Also, the only way to send events to the user interface from a program is through instrumentation.
This document describes how to test activities using instrumentation and other test facilities. The document assumes you have already readTesting Fundamentals, the introduction to the Android testing and instrumentation framework.
The Activity Testing API
The activity testing API base class is InstrumentationTestCase
, which provides instrumentation to the test case subclasses you use for Activities.
For activity testing, this base class provides these functions:
- Lifecycle control: With instrumentation, you can start the activity under test, pause it, and destroy it, using methods provided by the test case classes.
- Dependency injection: Instrumentation allows you to create mock system objects such as Contexts or Applications and use them to run the activity under test. This helps you control the test environment and isolate it from production systems. You can also set up customized Intents and start an activity with them.
- User interface interaction: You use instrumentation to send keystrokes or touch events directly to the UI of the activity under test.
The activity testing classes also provide the JUnit framework by extending TestCase
andAssert
.
The two main testing subclasses are ActivityInstrumentationTestCase2
andActivityUnitTestCase
. To test an Activity that is launched in a mode other thanstandard
, you use SingleLaunchActivityTestCase
.
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 invokes setUp()
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 in android.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 hidden MockApplication
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 use
findViewById(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 use
ActivityInstrumentationTestCase2
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 topic Handling 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 to Testing in Eclipse, with ADT. If you're not working in Eclipse, refer to Testing in Other IDEs.
If you want a step-by-step introduction to testing activities, try one of the testing tutorials:
- The Hello, Testing tutorial introduces basic testing concepts and procedures in the context of the Hello, World application.
- The Activity 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's UI 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 the run()
method, and instantiate a new instance of the class as a parameter to the methodappActivity.runOnUiThread()
, where appActivity
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
and sendKeys
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 call getActivity()
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 from setUp()
.
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.
← Back to Testing
- Android Activity 测试
- android activity 生命周期测试
- Android activity生命周期测试
- Android Activity 测试指南
- Android Activity生存周期测试
- Android测试教程(6):测试Activity
- Android测试教程(6):测试Activity
- android测试类:ActivityInstrumentationTestCase2<T extends Activity>
- Android的Activity的生命周期测试
- android-Junit测试单个activity一
- Android中Activity生命周期测试分析
- Android单元测试-对Activity的测试
- Android程序测试(2)——Activity测试
- Android训练课程(Android Training) - 测试你的Android Activity
- Activity测试
- [Android初级]android单元测试之Activity单独测试
- android学习:android Activity生命周期的七个方法测试
- android中Activity的生命周期(附测试源码)
- JavaScript DateTime格式化
- PB窗口之间传递多参数的方法
- 在Ubuntu 11.04 上安装Xilinx ISE 13.1指南,附出错的改正方法
- Armitage pentest
- C/C++内存与运行时深入研究
- Android Activity 测试
- error: expected '=', ',', ';', 'asm' or '__attribute__' before 'glbvar'
- 修改的页面
- poj3252排列组合 忙了一天 唉。。。
- CSDN安家啦!
- Android Content Provider 测试
- 基础知识 (php)
- oracle statspack
- 模板类的不完全实例化