在介紹完Unit test的章節後大家一定會有一個想法，沒測試到UI感覺很不踏實。這也是事實，我們不是寫純邏輯的後端程式，只用單元測試或許不太夠，而且單元測試中把UI元件的操作排除在外，怎麼能保證在App上實際操作沒有問題。因為只做單元測試是無法包涵所有的實際使用狀況，所以我們需要做Instrumentation Test來進一步確認App UI元件行為的正確性。

Instrumentation Test就是設備測試的意思，可以使用real device實體機器或是virtual device虛擬機器，設備測試依照測試範圍的不同可分為三個階段。

• Intrumentation Unit Test 某些狀況下，需要利用application context測試但是不需要運行UI介面，類似之前提到的無UI單元測試。
  • 優點：可不用UI testing framework就運行很簡單的context related測試。
  • 缺點：大部份邏輯可由無UI的單元測試完成，這裡需運行application process耗費時間，只測試小單元並不划算，可以直接包含在integration test內取代，因此較少機會使用。
• Integration Test 可以隨意呼叫App中的任何一個UI頁面，並給予不同mock條件來確認被測試元件執行多個functions或跨元件執行的正確性。
  • 優點：可以依照測試的需求，只呼叫任一個頁面的元件用來快速驗證UI行為的正確性，另外必須mock其它外部資源包含Server reqeust，local storage用以確認被測試元件的正確性，如果包含外部資源就無法確認測試失敗的原因。
  • 缺點：無法模擬真實使用者的操作行為，測試結果不代表app實際運行狀況，因為除了被測UI元件外，其它data都是利用mock方式得到。
• End to end test　模擬使用者行為，不用任何mocking data，必須使用與使用者操作App所使用的流程及data一致，也就是你必須與server連線及使用local storage（例如SharedPreference，Database等等。
  • 優點：因為所使用的data跟實際使用者一致所以最能顯示app品質的真實狀況
  • 缺點：使用上最耗費資源及時間，因為每次的流程都如使用者操作一樣，如果你要測試的步驟在最後一個頁面，你一樣要從登入頁面開始執行。另外一但發生錯誤最難debug，因為你不知道是程式寫錯還是其它環節出錯，如同使用者操作一樣回報錯誤必須花時間trace。

Intrumentation Test可以包含所有的測試，只要需要launch application process的測試都可以稱為Intrumentation Test。也因此你可以在Intrumentation Test的時候去順便跑無UI的Local Unit Test，但是一旦要launch application process執行效率會變很差沒人會這樣做。因此我們要把Unit Test和Intrumentation Test分開來做，必竟時間就是成本。

下一節會開始介紹Integration Test，Intrumentation Unit Test會忽略不講原因是使用機會不高，我個人也會在Integration Test的時候把它當成一個環節來測試。