#前言
终于着手写单元测试系列文章，这也将是我着手写系列文章的第一篇。
之所以决定用单元测试作为系列文章第一篇，是因为最近才捡起来写文章的习惯，并且现在公司也开始重视起了单元测试，了解一番后发现单元测试真是个好东西，随着时间积累下来更是会方便你我他，重构代码不担心，新人接手也可以借助单元测试了解逻辑。
那么为什么直到今天，编写单元测试仍然没有那么普及呢？ 我认为主要的原因就是决策的人大部分都不是程序员出身，不知道单元测试的重要性。需求满足要求，运行没问题，就OK。殊不知，能运行只是第一步。
好的代码设计会让程序更健壮的运行下去，扩展也相对容易，这些需要一步步重构才能达成。单元测试正是重构的前提，重构的依赖，没有单元测试的重构，每一步都是心惊胆战,没有保障的。
所以我们今天来聊一聊 Android 中的单元测试。
#经典的单元测试框架—JUnit
App 模块的 build.gradle 文件中自动导入了 JUnit 依赖库，无需再次引入 JUnit 依赖
*JUnit* 依赖 *JVM* 虚拟机，可以测试 *Android* 中不依赖 *Android* 虚拟机的代码。
举一个用烂的例子：
public int sum(int a, int b){
return a + b;
}
这个方法无需依赖 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面板中，找到相关构建脚本，双击即可运行。此时运行的是整个模块下的所有测试用例
#结束语
本文仅是 Android 中单元测试系列文章中的第一篇文章，后面的文章会介绍几个别的框架，提出一些常见问题的解决方案，并且结合实际场景讲解单元测试的套路，欢迎关注…