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