基本单元测试框架
最开始建议先学习Junit & Mockito。这两款框架是java领域应用非常普及，使用简单，网上文章非常多，官网的说明也很清晰。junit运行在jvm上，所以只能测试纯java，若要测试依赖android库的代码，可以用mockito隔离依赖（下面会谈及）。
之后学习AndroidJUnitRunner，Google官方的android单元测试框架之一，使用跟Junit是一样的，只不过需要运行在android真机或模拟器环境。由于mockito只在jvm环境生效，而android是运行在Dalvik或ART，所以AndroidJUnitRunner不能使用mockito。
然后可以尝试Robolectric & Espresso。Robolectric运行在jvm上，但是框架本身引入了android依赖库，所以可以做android单元测试，运行速度比运行在真机or模拟器快。但Robolectric也有局限性，例如不支持加载so，测试代码也有点别扭。当然，robolectric可以配合junit、mockito使用。Espresso也是Google官方的android单元测试框架之一，强大就不用说了，测试代码非常简洁。Espresso本身运行在真机上，因此android任何代码都能运行，不像junit&mockito那样隔离依赖。缺点也是显而易见，由于运行在真机，不能避免“慢”。
其实espresso应该是几款框架中最简单的，但笔者还是建议先学习junit&mockito。因为新手很可能会因为espresso的强大、简单，而忽略了junit做单元测试带来的巨大意义。例如，前文提到“快速定位bug”、“提高代码质量”，espresso慢，有违“快速”；用espresso不用修改工程任何代码，这不利于提高代码质量。
本文主要介绍junit和mockito，以及单元测试一些重要概念。
Junit
先给大家上两段代码压压惊：
public class Calculater { public int add(int a, int b) { return a + b; } } |
AssertEquals
单元测试用例：
public class CalculaterTest { Calculater calculater = new Calculater(); @org.junit.Test public void testAdd() { int a = 1; int b = 2; int result = calculater.add(a, b); Assert.assertEquals(result, 3); // 验证result==3，如果不正确，测试不通过 } } |
以上是一个要测试的类Calculater和测试用例CalculaterTest。在Intellij或Android Studio对类右键->run CalculaterTest，用例中所有被@org.junit.Test注解的方法，就会被执行。
run calculaterTest
pass
测试通过。
如果代码改成Assert.assertEquals(result, 4);，测试会失败。
not pass
Verify
verify的作用，是验证函数是否被调用（以及调用了多少次）。
public class CalculaterTest { @org.junit.Test public void testAdd2() { calculater = mock(Calculater.class); calculater.add(1, 2); verify(calculater).add(1, 2); // 验证calculater.add(a, b)是否被调用过，且a==1 && b==2 // 测试通过 } } |
是不是很简单？
Mockito
官网这样描述：
Mockito is a mocking framework that tastes really good. It lets you write beautiful tests with a clean & simple API.
大概意思是，Mockito是一个体验很好的mocking框架，它可以让你写出漂亮、简洁的测试代码。
什么是mocking？下文会详细说明。不如先让你感受一下mockito代码：
public interface IMathUtils { public int abs(int num); // 求绝对值 } |
import static org.mockito.Mockito.mock; import static org.mockito.Mockito.when; public class MockTest { public static void main(String[] args) { IMathUtils mathUtils = mock(IMathUtils.class); // 生成mock对象 when(mathUtils.abs(-1)).thenReturn(1); // 当调用abs(-1)时，返回1 int abs = mathUtils.abs(-1); // 输出结果 1 Assert.assertEquals(abs, 1);// 测试通过 } } |
可以发现IMathUtils是一个接口，根本就没有实现，用Mockito框架mock之后，IMathUtils.abs(-1)就有返回值1了。这就是Mockito神奇的地方！Mockito代理了IMathUtils.abs(num)的行为，只要调用时符合指定参数（代码中指定参数-1），就可以得到映射的返回值。
Mockito的语法when...thenReturn...相当直观，只要你小学有学英语_都能看懂。
读者肯定认为Mockito用了Java代理，实际上要更高级一点，Mockito底层用了CGLib（github/cglib）做动态代理。
依赖隔离
依赖隔离，这是单元测试中一个非常重要的概念。一个单元的代码，通常会有各种依赖。写单元测试时，应该把这些依赖隔离，让每个单元保持独立。举个例子：
public class Calculater { public double divide(int a, int b) { // 检测被除数是否为0 if (MathUtils.checkZero(b)) { throw new RuntimeException("dividend is zero"); } return (double) a / b; } } |
public class MathUtils { public static boolean checkZero(int num) { return num == 0; } } |
divide(a,b)计算a除以b，但被除数b不应该为0，所以用MathUtils.checkZero(b)验证b==0。咋看这里好像没什么问题，但是，如果MathUtils.checkZero里面的判断逻辑写错呢？例如：
public static boolean checkZero(int num) { return num != 0; // bug } |
如果不是num==0那么简单，而是更复杂的算法呢？
因为Calculater引用的任何依赖，都可能出错。更糟糕的是，如果用junit做单元测试，依赖里面可能是Android库或者jni native方法，依赖方法一执行就会报错。以上的各种原因，都会影响单元测试的结果。所以，我们对代码做如下改进：
public class Calculater { IMathUtils mathUtils; public double divide(int a, int b) { if (mathUtils.checkZero(b)) { throw ... } return (double) a / b; } } |
public interface IMathUtils { public boolean checkZero(int num); } |
我们可以在Calculater构造方法传入IMathUtils派生类，又或者用setter。在项目执行代码中，传MathUtils，而单元测试时，可以写一个MathUtilsTest继承IMathUtils，传给Calculater。只要保证MathUtilsTest.checkZero()正确就行。经过这么重构，Calculater就不依赖原来的MathUtils，单元测试时可以替换专门的实现，达到了依赖隔离的目的。
有同学会问，这样岂不是每个依赖都要写一个专门给单元测试的类吗？这就等于拷贝多一份代码，并且写各种接口，而且不能保证单元测试的类一定正确。
说得很有道理。笔者为了尽量简单地演示代码，举了一个非常简单的例子。我们如何让单元测试更简洁，并且让它阅读起来更有意义呢？
Mock
为了更好地解决上述问题，我们引入Mock概念。Mock，翻译为模拟，在单元测试mock可以模拟返回数据，也可以模拟接口/方法的行为。
什么是模拟行为？例如刚才mathUtils.checkZero(b)，意义为：“当mathUtils调用checkZero(num)”时，判断 num==0；又或者：“当调用checkZero(0)时返回true，num为其他值时返回false”。checkZero()是一个行为，返回的true、false就是数据。单元测试时，我们经常要让方法/接口模拟某些行为，并得到模拟数据。
例如，需要测试a=2,b=1和a=2,b=0调用divide(a,b)两者结果分别是2，抛出错误，使用mockito框架让mathUtils.checkZero()模拟行为，代码如下：
public static void main(String[] args) { // 生成IMathUtils模拟对象 IMathUtils mathUtils = mock(IMathUtils.class); when(mathUtils.checkZero(1)).thenReturn(false); // 当num==1时，checkZero(num)返回false when(mathUtils.checkZero(0)).thenReturn(true); // 当num==0时，checkZero(num)返回true Calculater calculater = new Calculater(mathUtils); assertEquals(calculater.divide(2,1), 2); // 验证 divide(2,1) 结果是2 try { calculater.divide(2, 0); // 预期抛出错误 throw new RuntimeException("no expectant exception"); // 如果divide没抛错，则此处抛错 } catch (Exception e) { Assert.assertEquals(e.getMessage(), "dividend is zero"); // 验证错误信息 } } |
这段测试代码可以运行通过！
代码剖析：
mock(IMathUtils.class)生成IMathUtils类的模拟对象(称mock对象)。这个mock对象调用任何方法都不会被实际执行；
when(mathUtils.checkZero(1)).thenReturn(false)，当调用checkZero(num)并且num==1，返回false，这里mockito模拟了checkZero()行为，并模拟了返回数据；
所以，calculater.divide(2,1)返回结果2，calculater.divide(2, 0)抛出RuntimeException。
以上例子描述了，使用mockito模拟类方法和返回数据，通过mock隔离了Calculater对IMathUtils实现类的依赖，并通过单元测试，验证了divide()的逻辑正确性。
条件覆盖
无限条件
要验证程序正确性，必然要给出所有可能的条件（极限编程），并验证其行为或结果，才算是100%覆盖条件。实际项目中，验证边界条件和一般条件就OK了。
还是上面那个例子，只给出两个条件：a=2,b=1和a=2,b=0，a=2,b=1是一般条件，b=0是边界条件，还有一些边界条件a=NaN，b=NaN等。要验证除法正确性，恐怕得给出无限的条件，实际上，只要验证几个边界条件和一般条件，基本认为代码是正确了。
有限条件
再举个例子：stateA='a0'、'a1', stateB='b0'、'b1'、'b2'，根据stateA、stateB不同组合输出不同结果，例如a0b0输出a0b0，a0b1输出a0b1，所以，共2*3=6种情况。这时，并不存在边界条件，所以条件都是特定条件，并且条件有限。
这种情况在项目中很常见，以笔者经验，建议单元测试时把所有情况都验证一遍，确保没有遗漏。
单元测试不是集成测试
集成测试
集成测试，也叫组装测试、联合测试。在单元测试的基础上，将相关模块组合成为子系统或系统进行测试，称为集成测试。通俗一点，集成测试就是把多个（最少2个）组件合在一起，测试某个功能片段，甚至是单独功能。
单元测试仅针对单元
在微信群很多同学问：“用Robolectric能不能请求网络”，"Junit能直接请求服务器吗"？
例如，我们使用MVP模式，如果我们想测试：调用PresenterA接口，请求真实网络，并且返回数据后，解析成对象，并且根据返回数据执行对应逻辑。这明显就是一个集成测试，而不是单元测试。PresenterA是一个单元，M层的Repository、DAO等是一个单元，更底层的sqlite第三方库、网络请求第三方库(okhttp等) 也是单元.....组合了n个单元的测试，是集成测试。
Robolectric、Junit能否请求网络？
包括笔者在内，很多同学一开始都会有这个疑问。
阅读了本文第一部分，应该了解到robolectric、junit是运行在jvm，只要有一点点java开发经验的同学，都知道jvm本身能连接网络。如果你调用的方法所依赖的一切代码，都不依赖Android库（例如okhttp、retrofit），那99%都能在jvm上跑，并且能请求服务器。如果不幸有Android依赖，很大概率还是能在robolectric上跑的。
为什么robolectric不是100%能跑通测试呢？Robolectric仅支持API21及以下，并且不支持jni库。因此，如果你的代码依赖了API21以上接口或者jni接口，robolectric也无能为力。天啊！怎么办？
请读者先不要沮丧，我们自有对策，不过要看读者慧根了_！。前文“依赖隔离”提到，我们可以通过一定手段，把jni、android依赖隔离掉。咦？咱们的代码是不是有救了？之后的文章，笔者会详细给大家讲解一下。
单元测试才是必要的
经过笔者指点，可能有读者蠢蠢欲动去尝试集成测试了.....且慢！说好的单元测试呢？集成测试看起来简单，实际上由于依赖过多，很多时候很麻烦，而且运行慢；相比之下，单元测试则小巧、灵活得多，运行快，快速发现bug。在这方面，有一个理论Test Pyramid：
Test Pyramid
示意图中，左箭头表示速度，右箭头表示开发成。可以看到，单元测试速度比集成测试（Service，也叫Integration）、UI测试要快，并且开发成本也是最低。Test Pyramid告诉我们，应该花大部分精力去写单元测试，其次才是集成测试、UI测试。
笔者建议，还是先老老实实做单元测试，有时间精力再做集成测试。
小结
本文介绍了几个单元测试框架，介绍了junit、mockito初步使用，阐述了依赖隔离、mocking的概念，解答了"robolectric、junit能否请求网络"问题。
如果读者问笔者：“我的是小项目，是否有必要做单元测试？” 我很肯定地回答，任何项目都有必要做单元测试。至于单元测试是否耗费很多时间，或者效果不显著，这要看使用者的编程经验了，不能一概而论。
最后，叮嘱读者多敲代码，真枪实弹地实践单元测试。可以从公司项目小规模使用，形成自己单元测试风格后，就可以跟大范围地推广了。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
