Activity

  • 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.
  •  
  • 输入验证:测试一个activity对EditText View输入做出正确地反应.设置按键顺序,并且发送到activity中,还有使用findViewById()用来验证View的状态是否正常.你可以验证一个有效的按键序列在OK按钮上是有效的,当输入一个无效的按键会使按钮失效.你也可以验证当输入无效的设置在View中activity会做出何种反应.
  •  
  • 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.
  •  
  • 生命周期事件:测试你每一个应用程序activity 的 handles 在 生命周期里面都是正确的.通常来讲,生命周期事件都是action动作,任何来自于系统或者用户,将会触发回调方法,例如onCreate()或者onClick().举个例子,一个activity应该对pause或者destoryed做出反应来并且保存它的状态.记住,实际上屏幕方向的改变事件会导致当前activity被销毁,所以你应该测试程序在设备运行中发生意外事件时不会偶然间丢失程序的状态.
  •  
  • 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.
  •  
  • Intens:测试每一个activity对指定在manifest的intent-filter里的intents做出正确的处理.你可以使用ActivityInstrumentationTestCase2发送一个模拟Intents 到activity 在测试中
  •  
  • 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.
  •  
  • 改变运行时的设置:在程序运行时,测试每个activity都能对可能改变的设备配置做出正确的响应.这些改变包括改变设备的屏幕方向,改变当前语言,等等.Handing这些改变具体描述在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.
  •  
  • 屏幕的兼容性:在你发布你的程序之前,请确认测试好所有你想运行的屏幕大小.你可以使用AVDs测试你的应用程式在多种屏幕大小下,或者你可以直接测试你的程序在目标设备上.更多的信息,可以看这篇Supporting Multiple Screens.

Content Provider

  • 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.
  •  
  • 测试解析方法:尽管你可以在providerTestCase2中实现一个provider,但是你应该始终用一个resolver对象测试合适的 URI.这可以确保你正在测试的provider 是在同一个应用程序中使用同样的操作.
  •  
  • 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:
  •  
  • 测试一个公共的provider的协定:如果你想你的provider是一个公共的和可被其它程序访问的,你应该测试它的协定.这里包括了一些主意:
    • 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.
    •  
    • 测试provider所有公开的常量.比如,在常量中有个列名是归类在provider’s data表中.这些常量应该始终定义在你的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.
    • 测试无效的URIs:你的单元测试应该故意的调用provider使用一个无效的URI,并且,查看这些错误.在使用无效的URIs时,好的provider的设计是会抛出一个IllegalArgumentException异常.
    •  
  • 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.
  •  
  • 测试标准的provider的操作.很多 providers 提供6个访问方法:查询,插入,删除,更新,获取类型,和onCreate().你的测试应该验证所有这些方法都是正常运行的.这些的详细描述可参阅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.
  •  
  • 测试业务逻辑:不要忘记测试业务逻辑你的provider是可以实现的.业务逻辑包括处理无效的数据,财务或者算术的计算,消除或者联级复制,等等.一个content provider 不要有太多的业务逻辑,因为,这可能导致改变数据时部分业务逻辑被实现.如果你的provider实现了业务逻辑,你应该测试它.

 

services

  • 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 triggersService.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.

  •  

  • 测试Service在Context.startService()的多次调用下正常运行.只有在第一次调用时触发Service.onCreate().但是,其它所有的调用都在Service.onStartCommand()触发.另外,记住startService()不支持嵌套调用!还有单独调用Context.stopService()或者Service.stopSelf()(但是不是stopSelf(int))将会停止Service.你应该测试你的Service在正确的点上停止.

  •  

  • Test any business logic that your Service implements. Business logic includes checking for invalid values, financial and arithmetic calculations, and so forth.
  •  
  • 测试Service实现的是所有业务逻辑.这些业务逻辑包括检查无效的值,财务和算术运算,等等


本文转自 liam2199 博客，原文链接： http://blog.51cto.com/youxilua/772686   如需转载请自行联系原作者