saii的专栏

简介 Espresso 是在2013年的 GTAC 上首次提出，目的是让开发人员能够快速地写出简洁，美观，可靠的 Android UI 测试。在你的项目中添加 Espresso其实说再多还是先动手实操才是最实际的。首先保证你的 Android Support Repository 已经成功安装在你程序的 build.gradle 文件中添加依赖 java // Force usage

之前一段时间通过同步更新开发的代码进行Espresso的测试，发现经常因为build.gradle的更新，进行会出现一些冲突的问题，当然也是个人能力的问题，总觉得经常花费时间在解决这些问题上有些不值当，所以Espresso的测试如果能够脱离源代码只需要依赖apk的话就更好了。 Espresso也是基于Instrumentation实现的，所以我们可以尝试通过robotium的方式来解决这个问题。

问题： 通过resign.jar重签名的apk后，安装运行后直接出现闪退的情况，查看log的原因是提示android.content.res.Resources$NotFoundException: File res/raw/praise.wav。其实通过这个提示信息就能够猜出一个大概了，就是我们使用resign.jar 对apk进行重签名的时候并没有将res/raw/目录下的文件打包重新打包进去。

我们都已经知道Espresso是基于Android instrumentation进行的自动化，而有了解的朋友们应该也是知道的 UiAutomator2.0也是基于 instrumentation的，那这两个是否能够一起使用呢。我们的答案是可以的。我们先拿网上的例子来说下简单的应用import android.support.test.InstrumentationRegistry;import

这段时间一直在使用espresso 进行Android 自动化测试，说句实在话，真是不实际用一下有很多东西都不会明白吧。下来列举两个遇到的问题以及解决的方法吧界面存在一个viewpager，viewpager中的内容是两个Recyclerview并且他们的resourceId都是一致的，这个时候，如果了解espresso的大概都能知道如果我简单的通过onView=(withId(recyclerv

Espresso有个很强大的功能就是能够同步测试操作。这样子就免去了我们经常在UiAutomator里面的Sleep的操作了。默认情况下，Espreeso会等待UI的事件被消息队列处理后，并且等待AsyncTasks完成后，才会去执行下一个操作。然而实际中，有许多的应用后台的操作都是使用自定义的服务去创建以及管理线程的。这个时候Espresso就无法做到同步了，那么有办法来解决这个问题吗？有的。可以

随着Android 5.x的普及，它的一些特性也在越来越多的APP中使用到，其中RecyclerView就是其中一个。RecyclerView 是一个像 ListView、GridVIew 那样呈现数据集合的 UI 组件，实际上它的目的是要替换掉这两个组件。从测试的角度上来看我们感兴趣的有是 RecyclerView 不是一个 AdapterView，这意味着你不能使用 onData() 去跟你的

前言由于Espresso 也是用于做UI自动化测试的，所以我们难免要拿它来跟UiAutomator进行比较了。 使用过UiAutomator的都应该知道，它不支持中文的输入，为此Appium引入了专门的appium的输入法来解决这个问题，那我们来试试看Espresso是否能够支持中文呢。中文的支持 onView(withId(R.id.editTextUserInput)).perform(type

前面我们已经简单的介绍了Espresso的环境搭建 Espresso 自动化测试（一） 以及有关Espresso的组件构成。下来我们来看看Espresso的一些API,这里有一张图片包含了我们前面说的到 Matchers,ViewActions 和 ViewAssertions 。用法简单的用法我们就不在这里说明了，我们今天来讲下如何获取到一个textView中的内容,其实从刚才的内容的API中

在 Espresso 自动化测试（一） 中我们说过Espresso编写自动化就做三件事情：找某些东西、做某些事情、检查某些东西。下来我们就针对这三点，逐步来进行说明。介绍我们先看看下面这张图找某些东西Espresso 提供了onView() 方法用来查看UI上指定的元素，该方法如下:public static ViewInteraction onView(final Matcher<View> v

在日常的测试中，我们还可能碰到许许多多的测试点，如Toast内容的验证，AutoCompleteText的选择等。 这些测试项都有一个共同的特点。即不在主UI布局的结构(layout,及其include的layout)之中，是不能直接定位的。 所以这里就需要使用inRoot( ) 了。Toast 测试众所周知UiAutomator是不支持Toast的验证的，为此很多人都想了很多的办法，结果当然都是

用过UiAutomator的同学其实都应该清楚，SeekBar是一个相当大的痛点，因为我们能够做到最多的就是获取到SeekBar的坐标，再来点击相应的一个坐标。那么问题来了。我根本就不知道我点击的结果，更好的来讲就是我根本没办法精确的控制SeekBarSeekBar的设置以及获取其实SeekBar的设置以及获取跟我们前面文章 Espresso 自动化测试（三）－获取文本内容 有很多的相似。这里我

前面谈到的Listview的测试都是单独的一个。但是往往现在的App的设计基本是ViewPager+Listview/RecyclerView 这里的RecyclerView的处理与ListView不一致，我们会放到后续进行讲解。在前面我们有提及过，我们查找控件都是需要有个唯一的区别该控件的条件。如何该条件同时满足其他控件的话，程序就会报 AmbiguousViewMatcherException

在上一篇文章我们已经知道了简单的onData的使用了，但是我们都知道，在真正的测试中，我们的ListView或者GridView不可能为这么简单的数据的，所以我们还是需要用一些复杂的数据来进行测试。SimpleAdapter对于Android有一定了解的应该都对它有一定的了解吧。SimpleAdapter的构造函数是：public SimpleAdapter (Context context, L

在之前的文章中，我们简单介绍了Espresso的使用。通过onView()方法我们可以快速定位到界面上我们需要测试的目标元素。onView()比较适用于UI比较简单的情况，在不需要过于复杂的匹配条件的情况下是很方便的。但是，对于类似ListView这种有UI复用的元素来说，只是通过onView()就显得复杂了一点。其实我们看看onView的备注就知道来。/** * Creates a {@l

由于的espresso-contrib 2.2.1 库 依赖于com.android.support:appcompat-v7:23.1.1 导致我们在同时间使用不同版本的appcompat-v7 出现了冲突，dependency 配置如下：dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) tes