使用 Espresso 實現完整覆蓋的功能測試(3)

這是我為我們測試平臺定義的一個基本測試單位，也是我們整個測試方案里面的一個核心概念。這里有兩個方面需要明確一下。

• 有些人會說這是 Espresso 的標準寫法，因為你在定義一個 Espresso 測試文件時就必須要指定一個啟動的 Activity。但是從官方的 Demo 來看，他們傾向于這個 Activity 僅僅是一個入口，你應該在完成一條完成的測試用例（你可以根據需要跳轉到任何頁面）以后再進行相應驗證。但是在我們的這里，啟動的這個頁面（可以是 Activity 或者 Fragment）以后就只做當前頁面相關的邏輯測試，如果有頁面跳轉也僅僅是測試是否能成功跳轉，不會再對應的界面產生更多的交互。

• 由于 Espresso 是基于 JUnit 實現的，所以你可以針對單個頁面編寫多個獨立得測試用例，它們會以隨機的順序被調用。在我們的單頁面測試中，只有單一的測試入口，然后順序執行這個頁面需要執行的所有測試。

在單頁面測試中，會根據需求盡可能覆蓋這個頁面的所有的功能。這個時候有人可能會說，在不同的應用狀態下（比如：登錄是否），通過 UI 測試所能產生的邏輯并不一致，怎么做到全覆蓋能。我們的解決方案是在這個頁面的測試代碼中，需要全部覆蓋該頁面所有的邏輯分支，當開始執行這個單頁面測試的時候，是怎么樣的狀態，就進入怎樣的邏輯分支。這個時候又有人開始有疑問了，這樣怎么做到全功能覆蓋呢。想象力豐富的人可能已經想到了解決方案，我們先給到一張圖啟發一下，后面再介紹我們引入的下一個概念——測試流。

PS：如果使用的 MVP 的模式來編寫代碼的話，你會發現在單個頁面需要那些邏輯是非常清晰的。

雖然上面已經明確定義了單頁面測試的寫法，但是在實際應用過程中，還是會遇到一些場景，不在定義里面被約束，應該怎么處理會讓人產生疑惑，會對單頁面測試的能力的覆蓋性產生懷疑。下面我列出來的幾種情況常見的情況來解釋應該怎么堅持單頁面測試作為基本單位。

原文轉自：http://ohmerhe.com/2017/04/18/espresso_huge_ui_test/