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() or onClick(). 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 topic Supporting Multiple Screens.
Test with resolver methods: Even though you can instantiate a provider object in ProviderTestCase2, 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:
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.
Test all the URIs offered by your provider. Your provider may offer several URIs, each one referring to a different aspect of the data. The Note 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.
测试Provider提供的所有URIs.Provider可能提供一些URIs在data中每个都涉及到不同的方式.例如在NOTE PAD 例子中,比如,一个provider提供一个uri 用于回收一个列表的笔记记录,另外一个使用databas Id用于回收一条笔记记录,和 还有一个用于显示笔记在一个折叠面板上
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.
Ensure that the onCreate() is called in response to Context.startService() or Context.bindService(). Similarly, you should ensure that onDestroy() is called in response to Context.stopService(), Context.unbindService(), stopSelf(), or stopSelfResult().
确定onCreate()方法是响应Context.startService() 或者Context.binServ()的调用.同样,你应该确定onDestoy()方法是响应Context.stopService(), Context.unbindService(), stopSelf(), or stopSelfResult(). 的调用
Test that your Service correctly handles multiple calls from Context.startService(). Only the first call triggers Service.onCreate(), but all calls trigger a call to Service.onStartCommand().
In addition, remember that startService() calls don't nest, so a single call to Context.stopService() or Service.stopSelf() (but not stopSelf(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.