輸入驗證:測試一個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=)