在介紹我們的測試平臺方案之前,需要提前說明的是,我們在使用 Espresso 的方式可能和官方 Demo 里所展示的方式不完全一樣。為了讓我們寫的測試代碼能夠更加靈活和方便的被復用在不同的測試用例中,從而實現更低成本的全功能覆蓋,我們進行了一些方案設計,最后實現了我們現在的測試平臺。
給我們的測試方案取了一個高大上的名稱——ETP 測試方案,也就是 Espresso Test Platform 的簡稱。大家如果看過 Google 官方的 Demo 的話,就應該能理解官方的思路其實是每個測試是完成一條完整的邏輯測試,比如完成添加一個筆記的測試邏輯。
這樣的測試流程總結下來有兩個比較明顯的問題:
每條測試用例需要單獨編寫,代碼的復用性差,導致編寫單元測試的成本較高,雖然 Google 官方提供錄制測試腳本的功能,但是生成的代碼可用性并不強,大多數情況下還是需要靠人來編寫。
復雜場景的處理能力,這樣一條單獨的測試流程容易被觸發性的彈窗或者引導提示打斷,如果在單條測試中做過多的判斷,又會讓單條測試用例變得臃腫,從而讓所有的測試用例都變得臃腫而且難于維護和更新。
原文轉自:http://ohmerhe.com/2017/04/18/espresso_huge_ui_test/