声明：本系列文章是对 Android Testing Support Library官方文档的翻译，水平有限，欢迎批评指正。
一个布局可以包含多个本身并不唯一的视图（如联系人列表中的重播按钮，它们在视图结构中拥有相同的 R.id 值，相同的文字和属性）。
比如，在此 activity 中，包含文字 “7” 的视图在多行中重复出现：
此类非唯一的视图通常会与紧靠它的带有唯一标签的视图配对（如拨号按钮旁的姓名）。这种情况下，你可以使用 hasSibling 匹配器缩小选择范围：
onView(allOf(withText("7"), hasSibling(withText("item 0")))).perform(click());
如下 activity 包含一个 ListView，它基于一个为每一行提供一个 Map<String, Object> 类型的 SimpleAdapter。每个 map 都一个键为 “STR” ，的元素（值为 String 类型，“item: x”）和一个键为 “LEN” 的元素（值为 Integer 类型，字符串的长度）。
点击 “item: 50” 条目的代码如下：
onData(allOf(is(instanceOf(Map.class)), hasEntry(equalTo("STR"), is("item: 50))).perform(click());
我们先来看 onData 的一部分：
is(instanceOf(Map.class))
限制搜索 AdapterView 中任意条目的条件为一个 Map。
在此例子中，ListView 的所有行都满足条件。但我们想要点击指定的条目 “item: 50”，所以我们需要继续缩小范围：
hasEntry(equalTo("STR"), is("item: 50))
这个 Matcher<String, Object> 会匹配所有包含任意键，值=“item: 50” 的 Map 。鉴于查找此条目的代码较长，而且我们希望在其他地方重用它，我们可以写一个自定义的 matcher “withItemContent”：
return new BoundedMatcher<Object, Map>(Map.class) {
@Override
public boolean matchesSafely(Map map) {
return hasEntry(equalTo("STR"), itemTextMatcher).matches(map);
}
@Override
public void describeTo(Description description) {
description.appendText("with item content: ");
itemTextMatcher.describeTo(description);
}
};
}
我们使用 BoundedMatcher 作为基类，因为我们希望能够只匹配 Map 类型的对象。我们覆写了 matchesSafely 方法，将之前创建的匹配器带入，将其通过 Matcher<String> 传入进行匹配。此方式将允许我们使用 withItemContent(equalTo(“foo”))。为了代码简洁性，我们创建了另一个已经做了 equalTo 操作并接收一个 String 的匹配器：
public static Matcher<Object> withItemContent(String expectedText) {
checkNotNull(expectedText);
return withItemContent(equalTo(expectedText));
}
现在点击该条目的代码很简单了：
onData(withItemContent("item: 50")).perform(click());
此测试的完整代码请查看 AdapterViewText#testClickOnItem50 和自定义匹配器。
上述示例陈述了在 ListView 中点击一行的中间位置。但我们该如何操作一行中指定的子视图？例如，我们我们想要点击 LongListActivity 其中一行的第二列，该列展示第一列的 String.lenth（具象而言，你可以想象一下 G+ 应用中的评论，在每一条评论旁有一个 +1 按钮）：
在 DataInteraction 中添加一个 onChildView 说明：
onData(withItemContent("item: 60"))
.onChildView(withId(R.id.item_size))
.perform(click());
注意：此示例使用了上例中的 withItemContent 匹配器！参考 ApdaterViewTest#testClickOnSpecificChildOfRow60!
header 和 footer 通过 addHeaderView/addFooterView API 添加到 ListView 中。为了能够使用 Espresso.onData 加载它们，确保使用预置的值来设置数据对象（第二个参数）。
public static final String FOOTER = "FOOTER";
...
View footerView = layoutInflater.inflate(R.layout.list_item, listView, false);
((TextView) footerView.findViewById(R.id.item_content)).setText("count:");
((TextView) footerView.findViewById(R.id.item_size)).setText(String.valueOf(data.size()));
listView.addFooterView(footerView, FOOTER, true);
然后，你可以写一个匹配器来匹配此对象：
import static org.hamcrest.Matchers.allOf;
import static org.hamcrest.Matchers.instanceOf;
import static org.hamcrest.Matchers.is;
@SuppressWarnings("unchecked")
public static Matcher<Object> isFooter() {
return allOf(is(instanceOf(String.class)), is(LongListActivity.FOOTER));
}
在测试中很轻易就能加载该视图：
import static com.google.android.apps.common.testing.ui.espresso.Espresso.onData;
import static com.google.android.apps.common.testing.ui.espresso.action.ViewActions.click;
import static com.google.android.apps.common.testing.ui.espresso.sample.LongListMatchers.isFooter;
public void testClickFooter() {
onData(isFooter())
.perform(click());
...
}
请在 AdapterViewtest#testClickFooter 中查看完整示例代码。
ActionBarActivity 有两个不同的模式：普通的 ActionBar 和从选项菜单中创建的上下文 ActionBar。它们都有一个条目是一直可见的，而另外两个只在悬浮菜单中课件。当点击一个条目时，它会将一个 TextView 的内容改为点击条目的内容。
匹配两种 ActionBar 中的可见图标都很简单：
public void testClickActionBarItem() {
// We make sure the contextual action bar is hidden.
onView(withId(R.id.hide_contextual_action_bar))
.perform(click());
// Click on the icon - we can find it by the r.Id.
onView(withId(R.id.action_save))
.perform(click());
// Verify that we have really clicked on the icon by checking the TextView content.
onView(withId(R.id.text_action_bar_result))
.check(matches(withText("Save")));
}
针对上下文 ActionBar 的代码与之类似：
public void testClickActionModeItem() {
// Make sure we show the contextual action bar.
onView(withId(R.id.show_contextual_action_bar))
.perform(click());
// Click on the icon.
onView((withId(R.id.action_lock)))
.perform(click());
// Verify that we have really clicked on the icon by checking the TextView content.
onView(withId(R.id.text_action_bar_result))
.check(matches(withText("Lock")));
}
点击普通 ActionBar 悬浮菜单中的条目有点棘手，由于某些设备带有硬件悬浮菜单按钮（它们会打开选项菜单的悬浮条目），而某些设备带有软件悬浮菜单按钮（它们会打开一个普通悬浮菜单）。幸运的是，Espresso 为我们解决了此问题。
对于普通的 ActionBar：
public void testActionBarOverflow() {
// Make sure we hide the contextual action bar.
onView(withId(R.id.hide_contextual_action_bar))
.perform(click());
// Open the overflow menu OR open the options menu,
// depending on if the device has a hardware or software overflow menu button.
openActionBarOverflowOrOptionsMenu(getInstrumentation().getTargetContext());
// Click the item.
onView(withText("World"))
.perform(click());
// Verify that we have really clicked on the icon by checking the TextView content.
onView(withId(R.id.text_action_bar_result))
.check(matches(withText("World")));
}
如下是在带硬件悬浮菜单按钮设备的显示：
对于上下文 ActionBar 而言也很简单：
public void testActionModeOverflow() {
// Show the contextual action bar.
onView(withId(R.id.show_contextual_action_bar))
.perform(click());
// Open the overflow menu from contextual action mode.
openContextualActionModeOverflowMenu();
// Click on the item.
onView(withText("Key"))
.perform(click());
// Verify that we have really clicked on the icon by checking the TextView content.
onView(withId(R.id.text_action_bar_result))
.check(matches(withText("Key")));
}
查看完整示例代码： ActionBarTest.java。
执行过一系列操作之后，你会想要断言待测 UI 的状态。有时可是会是一个负面情况（例如，有些操作没有成功）。请记住，你可以通过 ViewAssertions.matches 将任意的 hamcrest 视图匹配器转换为一个 ViewAssertion。
在下面的例子中，我们使用了 isDisplayed 匹配器，并使用标准的 “not” 匹配器反转匹配结果：
import static com.google.android.apps.common.testing.ui.espresso.Espresso.onView;
import static com.google.android.apps.common.testing.ui.espresso.assertion.ViewAssertions.matches;
import static com.google.android.apps.common.testing.ui.espresso.matcher.ViewMatchers.isDisplayed;
import static com.google.android.apps.common.testing.ui.espresso.matcher.ViewMatchers.withId;
import static org.hamcrest.Matchers.not;
onView(withId(R.id.bottom_left))
.check(matches(not(isDisplayed())));
如果视图仍然是整个结构的一部分，上述方式可用。否则，你将得到一个 NoMatchingViewException，此时你需要使用 ViewAssertions.doesNotExit（见下面）。
如果视图不在视图结构中（如，界面切换到了另一个 activity），你应该使用 ViewAssertions.doesNotExist:
import static com.google.android.apps.common.testing.ui.espresso.Espresso.onView;
import static com.google.android.apps.common.testing.ui.espresso.assertion.ViewAssertions.doesNotExist;
import static com.google.android.apps.common.testing.ui.espresso.matcher.ViewMatchers.withId;
onView(withId(R.id.bottom_left))
.check(doesNotExist());
为了证明一个指定的数据条目不在指定的 AdapterView 中，你需要做些其他操作。我们需要找到指定的 AdapterView 并得到它持有的数据。此处不需要使用 onData()，而是使用 onView 查找 AdapterView，然后使用另一个匹配器处理该视图中的数据。
首先创建匹配器：
private static Matcher<View> withAdaptedData(final Matcher<Object> dataMatcher) {
return new TypeSafeMatcher<View>() {
@Override
public void describeTo(Description description) {
description.appendText("with class name: ");
dataMatcher.describeTo(description);
}
@Override
public boolean matchesSafely(View view) {
if (!(view instanceof AdapterView)) {
return false;
}
@SuppressWarnings("rawtypes")
Adapter adapter = ((AdapterView) view).getAdapter();
for (int i = 0; i < adapter.getCount(); i++) {
if (dataMatcher.matches(adapter.getItem(i))) {
return true;
}
}
return false;
}
};
}
接下来我们只需要使用一个 onView 查找指定的 AdapterView：
@SuppressWarnings("unchecked")
public void testDataItemNotInAdapter(){
onView(withId(R.id.list))
.check(matches(not(withAdaptedData(withItemContent("item: 168")))));
}
如果 id 为 list 的 AdapterView 中有一个条目与 “item: 168” 相同，则断言失败。
参考网址示例代码：AdapterViewTest#testDataItemNotInAdapter。
Espresso 的核心是它可以与待测应用无缝同步测试操作的能力。默认情况下，Espresso 会等待当前消息队列中的 UI 事件执行（默认是 AsyncTask）完毕再进行下一个测试操作。这应该能解决大部分应用与测试同步的问题。
然而，应用中有一些执行后台操作的对象（比如与网络服务交互）通过非标准方式实现；例如：直接创建和管理线程，以及使用自定义服务。
此种情况，我们建议你首先提出可测试性的概念，然后询问使用非标准后台操作是否必要。某些情况下，可能是由于对 Android 理解太少造成的，并且应用也会受益于重构（例如，将自定义创建的线程改为 AsyncTask）。然而，某些时候重构并不现实。庆幸的是 Espresso 仍然可以同步测试操作与你的自定义资源。
以下是我们需要完成的：
IdlingResource 接口并暴露给测试。Espresso.registerIdlingResource 注册一个或多个 IdlingResource 给 Espresso。参考 AdvancedSynchronizationTest 和 CountingIdlingResource 类以了解 IdlingResource 如何能使用。
需要注意的是 IdlingResource 接口是在待测应用中实现的，所以你需要谨慎的添加依赖：
// IdlingResource is used in the app under test
compile 'com.android.support.test.espresso:espresso-idling-resource:2.2.2'
// For CountingIdlingResource:
compile 'com.android.support.test.espresso:espresso-contrib:2.2.2'
使用一个自定义的失败处理器来替换 Espresso 默认的 FailureHandler 以允许增强（或区分）错误的处理。比如：截图或转储特别的调试信息。
示例 CustomFailureHandlerTest 演示了如何实现一个自定义的失败处理器：
private static class CustomFailureHandler implements FailureHandler {
private final FailureHandler delegate;
public CustomFailureHandler(Context targetContext) {
delegate = new DefaultFailureHandler(targetContext);
}
@Override
public void handle(Throwable error, Matcher<View> viewMatcher) {
try {
delegate.handle(error, viewMatcher);
} catch (NoMatchingViewException e) {
throw new MySpecialException(e);
}
}
}
此失败处理器用 MySpecialException 代替了 NoMatchingViewException，并委托其他的失败给 DefaultFailureHandler。CustomFailureHandler 可以在 Espresso 测试的 setUp() 中注册：
@Override
public void setUp() throws Exception {
super.setUp();
getActivity();
setFailureHandler(new CustomFailureHandler(getInstrumentation().getTargetContext()));
}
参考 FailureHandler 接口和 Espresso.setFailureHandler 获取更多信息。
很惊奇吧，但这是真的—— Android 支持多窗口。通常这对于用户和 Android 开发者来说是透明的（transparent 双关意）,在某些情况下多窗口是可见的（例如：在搜索控件中自动补全窗口绘制在主窗口之上）。为了方便，Espresso 默认使用一个启发模式来推测你想要与哪个窗口交互。你可以通过自己提供根窗口（亦称为 Root 匹配器）来决定要与哪个窗口交互。
onView(withText("South China Sea"))
.inRoot(withDecorView(not(is(getActivity().getWindow().getDecorView()))))
.perform(click());
和 ViewMatchers 的情况类似，我们提供了一组封装好的 RootMatchers。当然，你依然可以实现自己的匹配器。
更多信息请查看 示例 或者 GitHub 上的示例。
