输入验证:测试一个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 <code>onCreate()</code> or <code>onClick()</code>. 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被销毁,所以你应该测试程序在设备运行中发生意外事件时不会偶然间丢失程序的状态.
测试解析方法:尽管你可以在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中
测试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 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实现了业务逻辑,你应该测试它.
Test that your Service correctly handles multiple calls from <code>Context.startService()</code>. Only the first call triggers<code>Service.onCreate()</code>, but all calls trigger a call to <code>Service.onStartCommand()</code>.
In addition, remember that <code>startService()</code> calls don't nest, so a single call to <code>Context.stopService()</code> or <code>Service.stopSelf()</code> (but not <code>stopSelf(int)</code>) 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实现的是所有业务逻辑.这些业务逻辑包括检查无效的值,财务和算术运算,等等
<b></b>
本文转自 liam2199 博客，原文链接： http://blog.51cto.com/youxilua/772686 如需转载请自行联系原作者
![Android项目的依赖关系解析[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)