Google Espresso或Robotium
我必须使用自动化的UItesting工具，并且在使用Robotium与Google Espresso之间感到困惑。
两者之间的主要区别是什么？ 在一个中是否存在特征而不是另一个？
充分披露：我是Espresso的作者之一。
Espresso和Robotium都是基于工具的框架，这意味着他们使用Android Instrumentation来检查活动并与之交互。
在谷歌，我们最初使用的是Robotium，因为它比股票仪器更为方便（Robotium开发者为此目的而开发的）。 但是，这并不能满足我们对开发人员编写可靠testing的框架的需求。
Espresso在Robotium上的主要进展：
-
同步。 默认情况下，工具testing逻辑运行在与UI操作（在UI线程上处理）不同的（工具）线程上。 如果没有testing操作与UI更新的同步，testing将容易发生 – 即由于计时问题将会随机失败。 大多数testing作者忽略这个事实，有些添加睡眠/重试机制，甚至更less的实现更复杂的线程安全代码。 这些都不是理想的。 Espresso通过将testing操作和断言与被测应用程序的UI无缝地同步来保证线程安全。 Robotium试图用睡眠/重试机制来解决这个问题，这种机制不仅不可靠，而且会导致testing运行速度超过必要的速度。
-
API。 Espresso有一个小的，明确的和可预测的API，可以自定义。 您告诉框架如何使用标准的hamcrest匹配器来定位UI元素，然后指示它执行一个动作或检查目标元素上的断言。 您可以将此与Robotium的API进行对比，testing作者需要从30多种点击方法中进行select。 此外，Robotium暴露了像getCurrentActivity（目前什么意思？）和getView这样的危险方法，它允许您在主线程之外的对象上进行操作（参见上面的要点）。
-
清除故障信息。 Espresso努力在发生故障时提供丰富的debugging信息。 此外，您可以使用自己的故障处理程序自定义Espresso处理故障的方式。 我有一段时间没有尝试过，但之前版本的Robotium遭受了不一致的失败处理（例如，clickOnView方法会吞下SecurityException）。
与以前的答案相反，所有API版本都支持Espresso，其中包含大量用户（请参阅： http : //developer.android.com/about/dashboards/index.html ）。 它适用于一些较旧的版本，但对这些版本进行testing会浪费资源。 谈到testing… Espresso通过全面的testing套件（覆盖率超过95％）以及Google开发的大部分Android应用程序对每一项变化进行了testing。
Espresso比Robotium快得多，但只适用于某些SDK版本。
所以如果你想要一个适用于所有设备的testing，那就去Roboitum。 如果没有，去咖啡，不要忘了你还会在一段时间内成为betatesting者。
