Android Google Espresso 或 Robotium
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/20046021/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Google Espresso or Robotium
提问by Androidme
I have to use Automated UI test tool and I am confused between using Robotium vs Google Espresso.
我必须使用自动化 UI 测试工具，我对使用 Robotium 和 Google Espresso 感到困惑。
What are the major differences between the two? Are there features that exist in one but not the other?
两者之间的主要区别是什么？是否存在存在于一个中而不存在另一个中的特征？
回答by ValeraZakharov
Full disclosure: I am one of Espresso's authors.
完全披露：我是 Espresso 的作者之一。
Both Espresso and Robotium are instrumentation-based frameworks, meaning they use Android Instrumentationto inspect and interact with Activities under test.
Espresso 和 Robotium 都是基于仪器的框架，这意味着它们使用Android Instrumentation来检查被测活动并与之交互。
At Google, we started out by using Robotium because it was more convenient than stock instrumentation (hats off to Robotium developers for making it so). However, it did not satisfy our need for a framework that made writing reliabletests easyfor developers.
在谷歌，我们开始使用 Robotium，因为它比股票工具更方便（向 Robotium 开发人员致敬，因为它做到了）。但是，它并不能满足我们对框架的需求，该框架使开发人员可以轻松编写可靠的测试。
The major advances in Espresso over Robotium:
与 Robotium 相比，Espresso 的主要进步：
Synchronization. By default, instrumentation test logic runs on a different (instrumentation) thread than UI operations (processed on the UI thread). Without synchronization of test operations with UI updates, the tests will be prone to flakiness - i.e. will fail randomly because of timing issues. Most test authors ignore this fact, some add sleeps/retry mechanisms and even fewer implement more sophisticated thread safety code. None of these are ideal. Espresso takes care of thread safety by seamlessly synchronizing test actions and assertions with the UI of the application under test. Robotium attempts to address this with sleep/retry mechanisms, which are not only unreliable, but also cause tests to run slower than necessary.
API. Espresso has a small, well-defined and predictable API, which is open to customization. You tell the framework how to locate a UI element using standard hamcrest matchersand then instruct it to either perform an action or check an assertion on the target element. You can contrast this with Robotium's API, where the test author is expected to choose from 30+ click methods. Further, Robotium exposes dangerous methods like getCurrentActivity (what does current mean anyway?) and getView, which allow you to operate on objects outside of the main thread (see the point above).
Clear failure information. Espresso strives to provide rich debugging information when a failure happens. Further, you can customize the way failures are handled by Espresso with your own failure handler. I haven't tried it in a while, but prior versions of Robotium suffered from inconsistent failure handling (e.g. the clickOnView method would swallow SecurityExceptions).
同步。默认情况下，检测测试逻辑在与 UI 操作（在 UI 线程上处理）不同的（检测）线程上运行。如果测试操作与 UI 更新不同步，测试将容易出现片状 - 即会由于时间问题随机失败。大多数测试作者忽略了这个事实，一些添加了睡眠/重试机制，甚至更少实现更复杂的线程安全代码。这些都不是理想的。Espresso 通过将测试操作和断言与被测应用程序的 UI 无缝同步来确保线程安全。Robotium 尝试通过睡眠/重试机制来解决这个问题，这不仅不可靠，而且还会导致测试运行得比必要的慢。
应用程序接口。Espresso 有一个小的、定义明确且可预测的 API，它是开放的定制。您告诉框架如何使用标准hamcrest 匹配器定位 UI 元素，然后指示它执行操作或检查目标元素上的断言。您可以将其与 Robotium 的 API 进行对比，其中测试作者需要从 30 多种点击方法中进行选择。此外，Robotium 公开了危险的方法，例如 getCurrentActivity（current 到底是什么意思？）和 getView，它们允许您对主线程之外的对象进行操作（请参阅上面的点）。
清除故障信息。Espresso 力求在发生故障时提供丰富的调试信息。此外，您可以使用自己的故障处理程序自定义 Espresso 处理故障的方式。我有一段时间没有尝试过，但之前版本的 Robotium 遇到了不一致的失败处理（例如，clickOnView 方法会吞下 SecurityExceptions）。
Contrary to a previous answer, Espresso is supported on all API versions with significant number of users (see: http://developer.android.com/about/dashboards/index.html). It works on some of the older versions, but testing on those would be a waste of resources. Speaking about testing... Espresso is tested on every change by a comprehensive test suite (with over 95% coverage) as well as the majority of android applications developed by Google.
与之前的答案相反，所有具有大量用户的 API 版本都支持 Espresso（请参阅：http: //developer.android.com/about/dashboards/index.html）。它适用于一些较旧的版本，但对这些版本进行测试会浪费资源。说到测试…… Espresso 的每一个变化都经过了全面的测试套件（覆盖率超过 95%）以及 Google 开发的大多数 android 应用程序的测试。
回答by Snicolas
Espresso is much faster than Robotium, but only works on some SDK versions.
Espresso 比 Robotium 快得多，但仅适用于某些 SDK 版本。
So if you want a test that works on all devices, go for Roboitum. If not, go for espresso, and don't forget you will be a beta tester for still some time.
因此，如果您想要一个适用于所有设备的测试，请选择 Roboitum。如果没有，那就去喝 espresso，不要忘记你将在一段时间内成为 Beta 测试员。
