Android Test 1 - Overview

這是來自Android官方網站的建議，摘要在這篇blog裡面。

採用iterative development workflow

較小的cycle: 這要求programmer寫unit test，確保test cases都完整且通過
較大的cycle:較小cycle完成後，代表requirement做完了，進入正式的UI test (QC部門)

tests有三種類型，依照數量比例(建議 7 : 2 : 1)會形成一個testing pyramid:

unit test: 這是通常是最獨立的，沒有其他module dependency的測試，如果牽涉到其他module的input的話，就必須要做mockup(假資料)，但是即便通過所有的unit test不能給予此app正確運作的信心，只能說個別unit通過了自己設定的tests。

integration test: 這是比較中型規模的test，會把幾個相關聯的modules一起寫入test cases測試。

ui test: 這是以end user眼光來測試整個ui flow，是最大規模的tests。

Small tests (Unit tests)

這通常不需要在模擬器上跑，可以直接寫test code在開發環境中執行，如果需要使用到Android framework的話，通常使用mocked methods。

1. 一個open source Java-based Android framework mock是 Roboletric （根據google IO 2017，現在是google內部使用以及維護的open source project)

2. 另一個是Mockito，這提供一個改變過的android.jar，裡面沒有任何code，但是提供Mock介面
3. instrumented unit tests: 這沒用到mocks，但是由於遠比上面兩種花時間，所以最好用來測試在硬體上(而非模擬器)

Medium tests (Integration tests)

經過unit tests之後，我們可以做一些medium tests來看某些units交集的運作情況，由於數量仍然較large tests多，所以為節省時間主要是在模擬器或是cloud test services上測試，盡量測試各種hardware profiles。

基本上medium tests還是isolated tests。

Large tests (UI / use cases test)

這類tests要在前兩種較小的tests都通過後，才會進行，由於定義的test cases牽涉到了use cases，所以花費大量時間，在testing pyramid中規模最大，數量最少。

這邊可以支援的工具有:
AndroidJUnitRunner class
Android Testing Support Library

• JUnit4Rules
• Espresso
• UI Automator
• Android Test Orchestrator