前言
终于着手写单元测试系列文章，这也将是我着手写系列文章的第一篇。
之所以决定用单元测试作为系列文章第一篇，是因为最近才捡起来写文章的习惯，并且现在公司也开始重视起了单元测试，了解一番后发现单元测试真是个好东西，随着时间积累下来更是会方便你我他，重构代码不担心，新人接手也可以借助单元测试了解逻辑。
那么为什么直到今天，编写单元测试仍然没有那么普及呢？
我认为主要的原因就是决策的人大部分都不是程序员出身，不知道单元测试的重要性。需求满足要求，运行没问题，就OK。殊不知，能运行只是第一步。
好的代码设计会让程序更健壮的运行下去，扩展也相对容易，这些需要一步步重构才能达成。单元测试正是重构的前提，重构的依赖，没有单元测试的重构，每一步都是心惊胆战,没有保障的。
所以我们今天来聊一聊 Android 中的单元测试。
经典的单元测试框架—JUnit
App 模块的 <font color=green>build.gradle</font> 文件中自动导入了 JUnit 依赖库，无需再次引入 JUnit 依赖
JUnit 依赖 JVM 虚拟机，可以测试 Android 中不依赖 Android 虚拟机的代码。
举一个用烂的例子：
这个方法无需依赖 Android 中的包，所以可以放心大胆的用 JUnit 编写单元测试用例。
假设这个 sum 方法是 A.class 文件中的一个方法，我们针对此方法可用如下代码编写单元测试：
1、在相应路径下创建单元测试类
2、编写单元测试函数
@Test
public void addition_isCorrect() throws Exception {
A a = new A();
assertEquals(4, a.sum(2, 2));
}
@Test 注解表示这是一个单元测试用例，并且能直接运行这个用例。
assertEquals 方法从含义中就可以看出是判定两个参数是否相等。
JUnit 中还有一个常用的注解，就是 @Before 注解。
被该注解修饰的方法，会在该类的每个单元测试方法最前面执行自己方法中的代码。主要用在你的测试用例都有一样的初始化代码，这些代码就可以写到用 @Before 注解修饰的方法内。
assertEquals 只是 JUnit 断言中的一种，下面是我从某学院网站中截得一张图，需要的时候可以看一下：
3、运行单元测试用例
第一种方式，直接在单元测试类文件上右键运行，此时是运行整个类中的单元测试用例
第二种方式，直接在方法代码中右键，单独运行这个单元测试用例，而不是整个类的所有测试用例
第三种方式，可以在gradle面板中，找到相关构建脚本，双击即可运行。此时运行的是整个模块下的所有测试用例
