Android單元測試(2)

　　使用Instrumentation Test時，不能脫離手機驗證代碼的正確性，但是可以節省用戶在手機上操作的時間，也就省去了在手機上反復重復操作的麻煩，也能直接輸出測試結果，可以很明顯的根據測試結果的顏色知道代碼邏輯是否正常，而通常的自測還需要思考。這種方式的驗證操作需要2min20s左右。

　　所以如果我們能使用JUnit的單元測試時，盡量使用這種單元測試，能極大地提升自測的效率，某些情況下不能使用JUnit的單元測試，這時候就適合使用 Instrumentation Test，比如，需要本地代碼的測試，就需要使用Instrumentation Test。而如果只是依賴執行本地代碼的類的話，可以用Robolectric + PowerMock +Mockito 進行模擬，模擬Native類的函數，使得調用Native類的函數返回預期的值即可實現模擬，進行正常的JUnit 單元測試。Robolectric將Android的Api在PC上做了重新實現，是一套非常強大的框架，支持Android的 SharedPreference，Environment, Context，甚至支持資源文件的使用(包括layout, drawable)，這樣我們的應用代碼不用做任何改動，就可以使用Robolectric框架在PC上執行，因為Robolectric實現了 Android的api，并且能在PC上運行。正是因為它，才能使得我們能脫離手機進行測試，非常強大。

　　非主分支無法保證正常執行的問題

　　當我們測試某個功能函數時，可以為它的各個分支準備不同的測試函數，每個測試函數準備不同的測試參數，對這個功能函數進行測試，確保每個分支都能執行到。我們還可以用代碼測試覆蓋率工具來收集測試用例對各個分支的覆蓋情況，比如jacoco工具，這樣能確保各個分支都能被測試到。

　　需要持續回歸測試的問題

　　我們可以通過和持續集成服務結合來解決這個問題。我們平常解決邏輯性Bug時，可以為這個Bug編寫測試用例，每次在Gitlab或者 Github上如果在某個分支上更新了代碼，則使得持續集成服務自動執行測試用例，這樣下次修改Bug時，如果導致現有邏輯出現了問題，持續集成服務執行測試用例時，會發現錯誤，然后會發郵件通知提交代碼的同事，說代碼有問題，讓其修改后提交。所有這些操作都是自動化的，可以節省大量人工測試時間，并且能提升測試效率。另外還可以將測試用例分成多組，比如SmallTest, LargeTest,MediumTest，在平常更新代碼時只執行SmallTest分組的測試用例，合并代碼時則執行LargeTest的測試用例，這樣可以極大地節省持續回歸測試的時間。

　　單元測試的局限性

　　從上面的論述看來，單元測試非常有用，但單元測試也有其局限性，整體的測試(集成測試)也是必不可少的。因為單元測試只能用于快速驗證某個程序單元的實現是否有問題，而不能保證各個程序單元之間相互配合也沒問題。

　　整體測試時也有自動化工具可以使用，比如Robotium, espresso，它們都是基于Android的Instrumentation Test實現的，也就是說如使用Robotium或者espresso編寫好自動測試用例后，可以在手機上執行自動化測試操作。常規的上線前用例的測試可以使用這種自動化工具提升測試效率，不需要手動操作，如果邏輯有問題，自動化測試工具可以自動報告這種錯誤。

　　Espresso是Google寫的，Google的工程師開始時也使用Robotium做自動化集成測試，在使用過程中發現存在不少問題，無法滿足他們的需求，所以他們就重新實現了Espresso。Android Studio開發中的版本2.2_preview3能實現錄制測試腳本，也就是說如果測試同學在手機上操作，AndroidStudio能將這些操作轉換成基于espresso的java測試用例代碼，然后下次測試時就可以直接執行這個測試用例了。所以如果想使用自動化的集成測試，還是建議使用 Espresso。

　　AndroidStudio2.2 preview 3中關于錄制測試腳本的網址如下所示: http://tools.android.com/tech-docs/test-recorder

　　Espresso相比Robotium的優點:

　　同步。 默認情況下，instrumentation test的邏輯并沒有在UI線程上執行，而是在單獨的線程里執行。如果不對測試操作和UI更新進行同步，那這些測試容易出現偶然性問題，比如說，將會因為時間的因素而隨機失敗。大部分測試人員都會通過sleeps/retry等機制，甚至通過復雜的線程安全代碼來進行測試。這幾種做法都是不理想的。 Espresso可以做到在測試時無縫同步測試操作斷言和應用的UI。Robotium通過sleeps/retry機制來處理這個問題，不僅不可靠，而且導致測試運行會更慢

　　API。 Espresso有更簡潔的API, 并且能支持定制。你只需通過標準的Hamcrest matchers來定位UI元素，然后在這個元素上指定某個操作或者在這個元素上進行斷言即可。而如果和Robotium的API相比，測試人員需要從 30多個click方法里進行選擇。并且Robotium也暴露了一些危險的方法比如說getCurrentActivity以及getView，可以讓你在非主線程上操作這些對象

原文轉自： http://www.cloudchou.com/android/post-909.html