Mockito.verify()
的api進行測試,這個測試類是TasksPresenterTest
,代碼如下:
@Test
public void loadAllTasksFromRepositoryAndLoadIntoView() {
//確保當前視圖是All視圖
mTasksPresenter.setFiltering(TasksFilterType.ALL_TASKS);
//第0步:開始加載數據
mTasksPresenter.loadTasks(true);
//驗證第2步:獲取待辦事項的邏輯有調用
verify(mTasksRepository).getTasks(mLoadTasksCallbackCaptor.capture());
//通過Mockito的Capture進行回調函數的測試,對應第3步
mLoadTasksCallbackCaptor.getValue().onTasksLoaded(TASKS);
//驗證第1步:進度條顯示
verify(mTasksView).setLoadingIndicator(true);
//驗證第4步:進度條關閉
verify(mTasksView).setLoadingIndicator(false);
ArgumentCaptor<List> showTasksArgumentCaptor = ArgumentCaptor.forClass(List.class);
//驗證第5步:View層顯示待辦任務列表
verify(mTasksView).showTasks(showTasksArgumentCaptor.capture());
//在Before周期里,事先初始化了3條待辦任務數據
assertTrue(showTasksArgumentCaptor.getValue().size() == 3);
}
注:這里涉及到異步回調函數如何測試的問題,使用Mockito的Capture可以解決此問題。具體細節,三言兩語說不清,后續考慮專門寫篇文章。
總結:讓Presenter充當個合格的皮條客,去調用其他兩層的邏輯,在假設其他兩層代碼邏輯都是正確的前提下,做一些mock測試,盡可能覆蓋所有邏輯路徑。
這一層的測試其實很清晰,站在QA的角度,我們想要驗證待辦任務列表時候,會設計以下的測試用例:
通過Espresso可以模擬這些步驟,并進行驗證,這個測試類是TasksScreenTest
,代碼如下:
@Test
public void showAllTasks() {
//添加2個待辦任務,對應第1、2、3步
createTask(TITLE1, DESCRIPTION);
createTask(TITLE2, DESCRIPTION);
//切換為All視圖,對應第4步
viewAllTasks();
//驗證Title1和Title2對應的Item存在,對應第5步
onView(withItemText(TITLE1)).check(matches(isDisplayed()));
onView(withItemText(TITLE2)).check(matches(isDisplayed()));
}
其中,createTask()的實現如下:
private void createTask(String title, String description) {
//點擊添加按鈕,對應第1步
onView(withId(R.id.fab_add_task)).perform(click());
//打開軟鍵盤,輸入標題和描述,對應第2步
onView(withId(R.id.add_task_title)).perform(typeText(title),
closeSoftKeyboard());
onView(withId(R.id.add_task_description)).perform(typeText(description),
closeSoftKeyboard());
//保存待辦任務,對應第3步
onView(withId(R.id.fab_edit_task_done)).perform(click());
}
viewAllTasks()的實現如下:
private void viewAllTasks() {
//點擊過濾按鈕
onView(withId(R.id.menu_filter)).perform(click());
//點擊ALL的選項
onView(withText(R.string.nav_all)).perform(click());
}
原文轉自:http://www.jianshu.com/p/cf446be43ae8