當涉及到頁面互相關聯的邏輯,一個典型的場景就是在訂閱頁面訂閱一個任務,然后在訂閱列表頁需要及時顯示最新添加的訂閱內容。官方的用例是把它放在一條測試里面就不用說了,在我們的測試方案里面應該怎么處理。
最后我們選擇的方案是分開測試:
在訂閱頁面進行訂閱相關測試,在這個頁面只驗證是否訂閱成功。
在訂閱列表界面,通過模擬訂閱操作,發送一個訂閱成功通知給這個頁面,測試該頁面是否會及時顯示最新的訂閱內容。
由于 Espresso 是以 Activity 為入口的,所以可能會導致產生一些誤會,我們的單頁面就是完全對應到 Activity,其實在我們的設計里面單頁面對應到的獨立子頁面的,所以 Fragment 可以作為一個單獨的「單頁面測試存在」。在我們的應用里面,首界面有三個 tab,所以加上 MainActivityTest 這個單頁面測試首界面總共有四個單頁面測試。
在應用中完成某些任務后,會發送一個全局的廣播,然后會在后臺觸發一些和當前頁面沒有什么關聯彈窗。這種場景對我們的 UI 測試是個挑戰,由于的隨機性,除非在每次都做大量重復的判斷,否則很容易導致 UI 測試被中斷失敗。
針對這樣的場景我們有個小伙伴提了一個特別好的解決方案: