Android单元测试 - 如何开始？

回顾：

《谈谈为什么写单元测试》

基本单元测试框架

Java单元测试框架：Junit、Mockito、Powermockito等；Android：Robolectric、AndroidJUnitRunner、Espresso等。

最开始建议先学习Junit & Mockito。这两款框架是java领域应用非常普及，使用简单，网上文章非常多，官网的说明也很清晰。junit运行在jvm上，所以只能测试纯java，若要测试依赖android库的代码，可以用mockito隔离依赖（下面会谈及）。

Junit官网
 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那样隔离依赖。缺点也是显而易见，由于运行在真机，不能避免“慢”。

Robolectric官网
 Android-testing-support-library官网

其实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能否请求网络"问题。结合阅读《谈谈为什么写单元测试》，想必读者对单元测试有了一个初步的了解。

如果读者问笔者：“我的是小项目，是否有必要做单元测试？” 我很肯定地回答，任何项目都有必要做单元测试。至于单元测试是否耗费很多时间，或者效果不显著，这要看使用者的编程经验了，不能一概而论。

最后，叮嘱读者多敲代码，真枪实弹地实践单元测试。可以从公司项目小规模使用，形成自己单元测试风格后，就可以跟大范围地推广了。欢迎在本文留言讨论！

下一篇：《Android单元测试 - 几个重要问题》

关于作者

我是键盘男。
在广州生活，在互联网公司上班，猥琐文艺码农。喜欢科学、历史，玩玩投资，偶尔独自旅行。