对于测试，大家都不陌生，但是我相信还是有部分开发觉得测试工作和自己没有直接关系、测试工作是测试工程师的事。惭愧的说，本人也是很长一段时间内没真正理解“测试”这件事儿，之前呆过的几家公司都没有真正的“测试工程师”，确切的说，是没有会写代码的测试工程师，基本上都是手动测试，然后输出报告，测试无需懂技术，我相信国内很多公司都是这样，特别是 App 端的测试，很少有白盒测试的。这篇要说的东西不多，主要来说说单元测试，由于本人也是最近才开始实践，文章抛砖引玉，如果有说得不到位的地方，希望读者给予指正。
0.1 什么是单元测试
0.2 单元测试的意义
0.3 Android 开发中进行单元测试
0.3.1 AndroidStudio 中配置
0.4 开源框架
0.5 MVP 架构中如何写单元测试
0.6 例子
我们先来做这么一个体验。假设现在我们有个开发者要完成某个功能的开发，现在我们从电脑屏幕的视角来观察他接下来的一序列行为：
他创建了一个类：A。
光标在同一个地方闪烁了好久，他应该在思考 ....
他在 A 写了一个方法 a。
接着写了方法b、c、d。
写的有点多了，滚动条来回滑动，他在阅读代码梳理逻辑。
他打开了启动器，运行了A。
运行报错了。
他继续修改方法。
再次打开启动器，运行了A。
运行成功了，他收获了满足感。
......
在这个观察中，我们看到他每次启动运行 A 所做的事其实就是“测试”，所以单元测试这件事其实是每个开发都做得最多的一件事，只是怎么让这件事变得更高效、更有意义是接下来要讲的。最后给出一个官方性的定义：**单元测试又称为模块测试, 是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。 程序单元是应用的最小可测试部件。**
我们先来看看一张图：
这张图叫做测试金字塔，单元测试处于开发环节比较早期，粒度也比较小，也是最重要的一个环节，对整体测试的效率至关重要，这部分做好了，后期的测试才会更有效，试想如果整栋楼建好了才发现砖头质量有问题，那是多么糟糕的事；单元测试就像对每个螺丝钉测试一样，生产螺丝钉的时候发现螺丝钉有问题很容易解决，如果在机器运转故障的时候去定位是不是螺丝钉、具体是那颗螺丝钉就难了。单元测试的意义可以总结如下几点：
代码质量的基础保障。
单元测试，模块区间比较小，更容易发现问题，发现问题更容易定位。
为后期集成测试节省了很多时间。
单元测试是对程序结构的一个观察者视角审视，有利于我们提高代码的整体设计能力。
AndroidStudio 中配置
Android 为我们提供了两种跑测试的方式：
Unit Tests
Android Instarumentaion Tests
Unit Tests
Unit Tests 这种方式，跑的测试代码运行在本机 JVM 上，不需要编译Apk ，不需要 Android 设备的支持，速度相对快，当然，测试的对象不能含有 Android 的 API，否则运行时会报错。这个模式下，测试代码的默认路径是 test／java。单元测试的基础框架是 Junit，需要配置依赖：
testCompile "junit:junit:4.12"
然后我们来写一个被测试类：Calculator.java
public class Calculator {
public int add(int a, int b) {
return a - b;
}
}
把Test Artifact 切换到 Unit Tests 模式，然后我们创建一个针对这个类的测试：CalculatorTest.java
选择 create new test
public class CalculatorTest {
@Before
public void setUp() throws Exception {
}
@After
public void tearDown() throws Exception {
}
@Test
public void testAdd() throws Exception {
}
}
自动生成了选择的测试方法，@Before、 @After、@Test 这几个注解来自 Junit 的 API，@Before 标记的方法，在测试用例启动时最先执行，然后执行 @Test 标记的方法，最后执行 @After 标记的方法。一般会在 @Before 的方法中做初始化工作，例如：创建被测试的对象， @Test 标记的就是我们要测试的方法，在其中执行验证方法。完善我们的测试代码：
public class CalculatorTest {
private Calculator calculator;
@Before
public void setUp() throws Exception {
calculator = new Calculator();
}
@After
public void tearDown() throws Exception {
}
@Test
public void testAdd() throws Exception {
// 验证方法执行结果，1＋1 是否等于 2
assertEquals(2, calculator.add(1 , 1));
}
}
然后在这个类上右键，我们就可以运行这个测试类了。
Android Instarumentaion Tests
Android Instarumentaion Tests 包的测试代码运行在 Android 设备上，速度相对慢一些。测试代码默认路径是 androidTest／java。为了让测试能跑在设备上，需要 AndroidJUnitRunner 的支持：
defaultConfig {
applicationId "com.dalimao.demoforunittest"
minSdkVersion 15
targetSdkVersion 23
versionCode 1
versionName "1.0"
// support Instarumentaion Tests
testInstrumentationRunner 'android.support.test.runner.AndroidJUnitRunner'
}
配置依赖：
androidTestCompile "com.android.support.test:runner:0.4.1"
同时也离不开 Junit 的支持，配置依赖：
androidTestCompile "junit:junit:4.12"
创建测试和 Unit Tests 的一样，运行的时候需要连接模拟器或手机。
测试框架很多，这里只简单说说比较流行的组合以及本例子中要使用的框架：
Junit 是最简单最基本的 Java 单元测试框架。
Mockito 强大的 Java 测试框架，强大之处在于能很方便的模拟对象，改变对象行为，同时提供了很多验证API。
espresso：google 提供的 U I测试框架。
理解了 AndroidStudio 中如何写最基本的单元测试，再结合几个开源框架，我们可以来写一些更为贴近实际开发的测试用例了。 目前 MVP 是 Android 项目的比较流行的架构模式，它的优点在代码的易测性。
上也得到了极好的体现，对 MVP 不熟悉的考验参考我之前的几篇博客：
对于 MVP 个层次我们怎么来写测试代码？ 先来看看框架的选型：
View层
View的测试自然依赖于Android环境，同时需要模拟U交互的能力，使用 Espresso + JUnit，Espresso用于模拟和验证各种各样的UI操作，使用 Android Instarumentaion Tests 运行，代码存放于AndroidTest中。
Presenter层
Presenter 上对UI，下对 Model 都是接口抽象，控制流程逻辑，不涉及 Android API，用 Junit + Mockito 测试即可，使用 Unit Tests 运行，代码存放于test中。
Model层
负责数据的存取，数据可能来自于网络、数据库和内存，如果涉及设备相关的API、依赖Android系统环境，则使用 Android Instarumentaion Tests 运行，代码存放于androidTest中；反之可以Junit+Mockito，使用 Unit Tests 运行，代码存放于test中。
1）场景介绍
这是一个简单的场景，一个游戏列表页面。对于列表页面，通常都会有缓存逻辑，加载数据时会优先去加载本地数据，如果没有，则加载远端数据。本例使用 MVP 来架构这个简单的场景（引入了 EventBus 来代替常规的异步回调，EventBus 极其简单，不过不理解也不影响对本章主题的理解），然后真对 M 和 P 分别写了对于的单元测试，**本例没有写 View 层的单元测试（个人觉得对 View 写单元测试的必要性不大，如果你的感受相反，非常感谢你给我一个说服我的理由）**，我们先来流程图：
至此，建议先你下载 demo 源代码，再一起完成下面的理解。**认真的人不会找不到源码地地址**
2）目录结构
test／java ：该目录下写了针对 GamePresenter 的单元测试 GamePresenterTest 和针对 GameManager 的测试类 GameManagerTest （这个跑不过，因为涉及类 Android 的 API）
androidTest / java： 该目录下写 针对 GameManager 的测试类 GameManagerAndroidTest （逻辑和 GameManagerTest 一样）
3）例子中涉及 Mockito 的注解和说明
@Mock ：对成员变量的注解，被这个注解的变量不用手动实例化，Mockito 会帮你注入一个模拟的对象（需要在 @Before 标记的方法中先执行 MockitoAnnotations.initMocks(this)。例如：
@Mock
private IGameManager gameManager;
初始化 MockitoAnnotations
public void setUp() throws Exception {
//Log 是 Android 的 API,Unit test 模式下关闭使用
LogUtil.setDebug(false);
// 初始化 @Mock 注解功能,自动注入 @Mock 标记的对象
MockitoAnnotations.initMocks(this);
//gameManager 已经实例化
}
verify(T)：这是 Mockito API 提供的一个静态方法，用来验证某个 mock 对象（@Mock 标记的对象）是否执行了某个方法，执行了多少次。verify(T)，返回是一个泛型，你传入什么类型他就返回什么类型的子类给你，重写的方法中验证传入对象对应的方法是否执行过。例如：
//验证 gameListView.showLoading() 是否执行
verify(gameListView).showLoading();
when(Object.method()).thenReturn(ReturnObject): 这是 Mockito API 提供的一个静态方法，用来改变方法的对象的行为（方法），当 Object.method() 调用的时候返回 ReturnObject ，用来模拟方法的返回值。例如本例中模拟获取本地数据为空：
//模拟本地数据为空
when(localGameDataSource.getData()).thenReturn(null);
福利君来啦！小伙伴们快奔走相告呐~
全开放免费注册，2天夜间技术交流、每场1.5小时深度分享、长时间互动 答疑、素材第一时间公开、用户组同步搭建。更有8位技术大牛线上与你 零距离！
