Android单元测试重构的前提

共计 1188 个字符，预计需要花费 3 分钟才能阅读完成。

终于着手写单元测试系列文章，这也将是我着手写系列文章的第一篇。

之所以决定用单元测试作为系列文章第一篇，是因为最近才捡起来写文章的习惯，并且现在公司也开始重视起了单元测试，了解一番后发现单元测试真是个好东西，随着时间积累下来更是会方便你我他，重构代码不担心，新人接手也可以借助单元测试了解逻辑。

那么为什么直到今天，编写单元测试仍然没有那么普及呢？

我认为主要的原因就是决策的人大部分都不是程序员出身，不知道单元测试的重要性。需求满足要求，运行没问题，就 OK。殊不知，能运行只是第一步。

好的代码设计会让程序更健壮的运行下去，扩展也相对容易，这些需要一步步重构才能达成。单元测试正是重构的前提，重构的依赖，没有单元测试的重构，每一步都是心惊胆战, 没有保障的。

所以我们今天来聊一聊 Android 中的单元测试。

App 模块的 <font color=green>build.gradle</font> 文件中自动导入了 JUnit 依赖库，无需再次引入 JUnit 依赖

JUnit 依赖 JVM 虚拟机，可以测试 Android 中不依赖 Android 虚拟机的代码。

举一个用烂的例子：

这个方法无需依赖 Android 中的包，所以可以放心大胆的用 JUnit 编写单元测试用例。

假设这个 sum 方法是 A.class 文件中的一个方法，我们针对此方法可用如下代码编写单元测试：

@Test
public void addition_isCorrect() throws Exception {A a = new A();
    assertEquals(4, a.sum(2, 2));
}

@Test 注解表示这是一个单元测试用例，并且能直接运行这个用例。

assertEquals 方法从含义中就可以看出是判定两个参数是否相等。

JUnit 中还有一个常用的注解，就是 @Before 注解。

被该注解修饰的方法，会在该类的每个单元测试方法最前面执行自己方法中的代码。主要用在你的测试用例都有一样的初始化代码，这些代码就可以写到用 @Before 注解修饰的方法内。

assertEquals 只是 JUnit 断言中的一种，下面是我从某学院网站中截得一张图，需要的时候可以看一下：

第一种方式，直接在单元测试类文件上右键运行，此时是运行整个类中的单元测试用例

第二种方式，直接在方法代码中右键，单独运行这个单元测试用例，而不是整个类的所有测试用例

第三种方式，可以在 gradle 面板中，找到相关构建脚本，双击即可运行。此时运行的是整个模块下的所有测试用例

前言