单元测试将测试中的组件隔离开，这就是为什么通常将Mocks框架与Mockito一起使用的原因:单位从他们的依赖关系.请注意，关于Android API的说法部分正确，因为还有仪器单元测试，即仪器也是Junit程序包的一部分，还有将TestCase扩展为类的类

Unit tests isolate the component under test, and this is the reason why are often used together with Mocks frameworks as Mockito:because isolate the unit from their dependencies. Please notice what you say regarding the Android API is partially true, because there are also Instrumented Unit tests, namely Instrumentation is part of the Junit package as well, and also the classes that extend TestCase as the class AndroidTestCase is part of the Junit package but allows the use of A)Context, that you can call with getContext(), and B)Resources that are part of the Android API! Also please consider AndroidTestCase is a base class and there are several other classes quite useful that extend this class. They test specifically Loaders, ContentProviders and even Services and also them have access to the Android API. so these classes provide JUnit testing framework as well as Android-specific methods. Now with Junit4 there is the ServiceTestRule that extends directly from Object and allow you easier to test a Service, although you cannot start an Intent directly inside this class.

仪器测试也包含在Junit程序包中，但是对Android API的控制是完全完全的，因为在运行任何应用程序代码之前，系统中都会对Instrumentation Tests进行实例化，并且需要测试打开真实的应用程序(仿真器或连接USB的手机).他们可以访问android组件(例如单击按钮)并延长应用程序的生命周期，通常比Junit测试(用于扩展TestCase的测试)(上述检查的测试)要慢，典型的用法是与ActivityInstrumentationTestCase2结合使用，该工具具有功能测试方法，面向用户.

Instrumentation tests they are also into the Junit package, but the control of the Android API is quite total because Instrumentation Tests are instantiated in the system before any application code is run, and to test you need to open the real application(emulator or a phone connected with USB). They access to android components(ex. click a button) and application life cycle, they are usually slower than Junit tests that extend TestCase( the ones examined above) the typical use is with ActivityInstrumentationTestCase2 that has a functional test approach, more user oriented.

关于Roboelectric和Mockito，它们是目前最流行的测试框架之间的Espresso的竞争者(2016年7月13日)， Roboelectric允许您在几秒钟内而不是几分钟内运行多个测试，这对于必须运行连续测试并且需要持续集成的团队来说非常方便.

Regarding Roboelectric and Mockito, that are togheter with Espresso between the most popular testing frameworks at the moment(13 July 2016), Roboelectric allows you to run multiple tests in seconds instead of minutes, and this comes really handy in teams that have to run continuous tests, and are subject to continuous integration.

来自Robolectric的站点:

From the site of Robolectric:

Robolectric的另一种方法是使用模拟框架，例如 Mockito或模拟出Android SDK.虽然这是有效的 方法，它通常会产生本质上相反的测试 应用程序代码的实现. Roboelectric可提供更接近黑盒测试的测试风格， 使测试更有效地进行重构并允许测试 专注于应用程序的行为，而不是 Android的实现.您仍然可以使用模拟框架 如果愿意，可以使用Robolectric.

An alternate approach to Robolectric is to use mock frameworks such as Mockito or to mock out the Android SDK. While this is a valid approach, it often yields tests that are essentially reverse implementations of the application code. Roboelectric allows a test style that is closer to black box testing, making the tests more effective for refactoring and allowing the tests to focus on the behavior of the application instead of the implementation of Android. You can still use a mocking framework along with Robolectric if you like.

Mockito也可以与Junit一起使用，实际上是在必须管理最终类，匿名类或原始类型的情况下使用.

Mockito that also can be used with Junit, is really used with the exception of when have to manage final classes, anonymous classes or primitive types.