关于单元测试，如何写出可测试的代码？

    单元测试在一个完整的软件开发流程中是必不可少的、非常重要的一个环节。通常写单元测试并不难，但有的时候，有的代码和功能难以测试，导致写起测试来困难重重。因此，写出良好的可测试的（testable）代码是非常重要的。接下来，我们简要地讨论一下什么样的代码是难以测试的，我们应该如何避免写出难以测试的代码，以及要写出可测试性强的代码的一些最佳实践。

什么是单元测试（unit test）？

　　通常一个单元测试主要有三个行为：

1. 初始化需要测试的模块或方法。
2. 调用方法。
3. 观察结果（断言）。

    这三个行为分别被称为Arrange, Act and Assert。以java为例，一般测试代码如下：

@Test
    public void isPalindrome() {

        //初始化：初始化需要被测试的模块，这里就是一个对象。
        //也可能没有初始化模块，例如测试一个静态方法。
        PalindromeDetector detector = new PalindromeDetector();

        //调用方法：记录返回值，以便后续验证。
        //如果方法无返回值，那么我们需要验证它在执行过程中是否对系统的其他部分造成了影响，或产生了副作用。
        boolean isPalindrome = detector.isPalindrome("kayak");

        //断言：验证返回结果是否和预期一致。
        Assert.assertTrue(isPalindrome);
    }

单元测试和集成测试的区别

    单元测试的目的是为了验证颗粒度最小的、独立单元的行为，例如一个方法，一个对象。通过单元测试，我们可以确保这个系统中的每个独立单元都正常工作。单元测试的范围仅仅在这个独立单元中，不依赖其他单元。而集成测试的目的是验证整个系统在真实环境下的功能行为，即将不同模块组合在一起进行测试。集成测试通常需要将项目启动起来，并且可能会依赖外部资源，例如数据库，网络，文件等。

良好的单元测试的特点

1. 代码简洁清晰

    我们会针对一个单元写多个测试用例，因此我们希望用尽量简洁的代码覆盖到所有的测试用例。

2. 可读性强

    测试方法的名称应该直截了当地表明测试内容和意图，如果测试失败了，我们可以简单快速地定位问题。通过良好的单元测试，我们可以无需通过debug，打断点的方式来修复bug。

3. 可靠性强

    单元测试只在所测的单元中真的有bug才会不通过，不能依赖任何单元外的东西，例如全局变量、环境、配置文件或方法的执行顺序等。当这些东西发生变化时，不会影响测试的结果。

4. 执行速度快

    通常我们每一次打包都会运行单元测试，如果速度非常慢，影响效率，也会导致更多人在本地跳过测试。

5. 只测试独立单元

    单元测试和集成测试的目的不同，单元测试应该排除外部因素的影响。

如何写出可测试的代码

    我们从一个简单的例子开始探讨这个问题。我们正在编写一个智能家居控制器的程序，其中一个需求是在夜晚触摸到台灯时自动开灯。我们通过以下方法来判断当前时间：

public static String getTimeOfDay() {

    Calendar calendar = GregorianCalendar.getInstance();
    calendar.setTime(new Date());
    int hour = calendar.get(Calendar.HOUR_OF_DAY);

    if (hour >= 0 && hour < 6) {
        return "Night";
    }
    if (hour >= 6 && hour < 12) {
        return "Morning";
    }
    if (hour >= 12 && hour < 18) {
        return "Afternoon";
    }
    return "Evening";
}

以上代码有什么问题呢？如果我们以单元测试的角度来看，就会发现这段代码根本无法编写测试， new Date() 代表当前时间，这是一个内嵌在方法里的隐含输入，这个输入是随时变化的，不同时间运行这个方法，返回的值也会不同。这个方法的不可预测性导致了无法测试。如果要测试，我们的测试代码可能要这样写：

@Test
public void getTimeOfDayTest() {
    try {
        // 修改系统时间，设为6点
            ...

        String timeOfDay = getTimeOfDay();

        Assert.assertEquals("Morning", timeOfDay);
    } finally {
        // 恢复系统时间
            ...
    }
}

像这样的单元测试违反了许多我们上述的良好的测试的特点，比如运行测试代价太高（还要改系统时间），不可靠（这个测试有可能因为设置系统时间失败而fail），速度也可能比较慢。其次，这个方法违反了几个原则：

1. 方法和数据源紧耦合在了一起

    时间这个输入无法通过其他的数据源得到，例如从文件或者数据库中获取时间。

2. 违反了单一职责原则（Single Responsibility Principle）

    SRP是指每一个类或者方法应该有一个单一的功能。而这个方法具有多个职责：1. 从某个数据源获取时间。 2. 判断时间是早上还是晚上。SRP的一个重要特点是：一个类或者一个模块应该有且只有一个改变的原因，在上述代码中，却有两个原因会导致方法的修改：1. 获取时间的方式改变了（例如改成从数据库获取时间）。 2. 判断时间的逻辑改变了（例如把从6点开始算晚上改成从7点开始）。

3. 方法的职责不清晰

    方法签名 String getTimeOfDay() 对方法职责的描述不清晰，用户如果不进入这个api查看源码，很难了解这个api的功能。

4. 难以预测和维护

    这个方法依赖了一个可变的全局状态（系统时间），如果方法中含有多个类似的依赖，那在读这个方法时，就需要查看它依赖的这些环境变量的值，导致我们很难预测方法的行为。

简单改进

public static String GetTimeOfDay(Calendar time) {

    int hour = time.get(Calendar.HOUR_OF_DAY);

    if (hour >= 0 && hour < 6) {
        return "Night";
    }
    if (hour >= 6 && hour < 12) {
        return "Morning";
    }
    if (hour >= 12 && hour < 18) {
        return "Noon";
    }
    return "Evening";
}

现在，这个方法没有了获取时间的职责，他的输出完全依赖于传递的输入。因此很容易对它进行测试：

@Test
public void getTimeOfDayTest() {

    Calendar time = GregorianCalendar.getInstance();
    //设置时间
    time.set(2018, 10, 1, 06, 00, 00);

    String timeOfDay = GetTimeOfDay(time);

    Assert.assertEquals("Morning", timeOfDay);
}

很好~这个方法具有了可测试性，但是问题依旧没有解决，现在获取时间的职责，转移到了更高层的代码上，即调用这个方法的模块：

public class SmartHomeController {

    private Calendar lastMotionTime;

    public void actuateLights(boolean motionDetected) {

        //更新最后一次触摸的时间
        if (motionDetected) {
            lastMotionTime.setTime(new Date());
        }

        // Ouch!
        Calendar nowTime = GregorianCalendar.getInstance();
        nowTime.setTime(new Date());

        //判断时间
        String timeOfDay = getTimeOfDay(nowTime);
        if (motionDetected && ("Evening".equals(timeOfDay) || "Night".equals(timeOfDay))) {
            //晚上触摸台灯，开灯！
            BackyardLightSwitcher.Instance.TurnOn();
        } else if (getIntervalMinutes(lastMotionTime, nowTime) > 1 ||
            ("Morning".equals(timeOfDay) || "Noon".equals(timeOfDay))) {
            //超过一分钟没有触摸，或者白天，关灯！
            BackyardLightSwitcher.Instance.TurnOff();
        }
    }
}

要解决这个问题，通常可以使用依赖注入（控制反转，IoC），控制反转是一种重要的设计模式，对于单元测试来说尤其有效。实际工程中，大多数应用都是由多个类通过彼此的合作来实现业务逻辑的，这使得每个对象都需要获得与其合作的对象（也就是他所依赖的对象）的引用，如果这个获取过程要靠自身实现，那会导致代码高度耦合并且难以测试。那如何反转呢？即把控制权从业务对象手中转交到用户，平台或者框架中。

引入了控制反转后的代码

public class SmartHomeController {

    private Calendar lastMotionTime;
    private Calendar nowTime;

    public SmartHomeController(Calendar nowTime) {
　　　　　this.nowTime = nowTime;
    }
 　　public void actuateLights(boolean motionDetected) {

        //更新最后一次触摸的时间
        if (motionDetected) {
            lastMotionTime.setTime(new Date());
        }

        //判断时间
        String timeOfDay = getTimeOfDay(nowTime);
        if (motionDetected && ("Evening".equals(timeOfDay) || "Night".equals(timeOfDay))) {
            //晚上触摸台灯，开灯！
            BackyardLightSwitcher.Instance.TurnOn();
        } else if (getIntervalMinutes(lastMotionTime, nowTime) > 1 ||
            ("Morning".equals(timeOfDay) || "Noon".equals(timeOfDay))) {
            //超过一分钟没有触摸，或者白天，关灯！
            BackyardLightSwitcher.Instance.TurnOff();
        }
    }
}

在之前代码中，nowTime的获取是由SmartHomeController自己实现的，引入控制反转后，nowTime是在初始化时由我们注入到对象中。如果使用spring框架，那注入的工作就由spring框架完成，即控制权转移到了用户或框架手中，这就是控制反转的意思。

接下来，我们就可以在测试中mock时间属性：

@Test
public void testActuateLights() {
    Calendar time = GregorianCalendar.getInstance();
    time.set(2018, 10, 1, 06, 00, 00);

    SmartHomeController controller = new SmartHomeController(time);

    controller.actuateLights(true);

    Assert.assertEquals(time, controller.getLastMotionTime());
}

 到这里，已经可以方便地对其做单元测试了，你认为这段代码已经具有良好的可测试性了吗？

方法的副作用（Side Effects）

我们仔细看这段开灯关灯的代码：

if (motionDetected && ("Evening".equals(timeOfDay) || "Night".equals(timeOfDay))) {
    //晚上触摸台灯，开灯！
    BackyardLightSwitcher.Instance.TurnOn();
} else if (getIntervalMinutes(lastMotionTime, nowTime) > 1 ||
    ("Morning".equals(timeOfDay) || "Noon".equals(timeOfDay))) {
    //超过一分钟没有触摸，或者白天，关灯！
    BackyardLightSwitcher.Instance.TurnOff();
}

这里通过控制 BackyardLightSwitcher 这个单例来控制台灯，这是一个全局的变量，意味着每次运行这个单元测试，可能会修改系统中变量的值。换句话说，这个测试产生了副作用。如果有其他的单元测试也依赖了 BackyardLightSwitcher 的值，那么测试的结果就变得不可控了。因此这个方法依旧不具有良好的可测试性。

函数式、一等公民

java8中引入了函数式和一等公民的概念。我们熟悉的对象是数据的抽象，而函数是某种行为的抽象。

其实我们可以看到，上述函数依旧不符合单一职责原则，它有两个职责：1. 判断当前时间。 2. 操作台灯。我们现在将操作台灯的职责从这个方法中移除，作为参数传递进来：

@FunctionalInterface
public interface Action {
    void doAction();
}

public class SmartHomeController {

    private Calendar lastMotionTime;
    private Calendar nowTime;

    public SmartHomeController(Calendar nowTime) {
        this.nowTime = nowTime;
    }

    public void actuateLights(boolean motionDetected, Action turnOn, Action turnOff) {

        //更新最后一次触摸的时间
        if (motionDetected) {
            lastMotionTime.setTime(new Date());
        }

        //判断时间
        String timeOfDay = getTimeOfDay(nowTime);
        if (motionDetected && ("Evening".equals(timeOfDay) || "Night".equals(timeOfDay))) {
            //晚上触摸台灯，开灯！
            turnOn.doAction();
        } else if (getIntervalMinutes(lastMotionTime, nowTime) > 1 ||
            ("Morning".equals(timeOfDay) || "Noon".equals(timeOfDay))) {
            //超过一分钟没有触摸，或者白天，关灯！
            turnOff.doAction();
        }
    }
}

现在，对这个方法做测试，我们可以将虚拟的行为传递进来：

@Test
public void testActuateLights() {
    Calendar time = GregorianCalendar.getInstance();
    time.set(2018, 10, 1, 06, 00, 00);

    MockLight mockLight = new MockLight();

    SmartHomeController controller = new SmartHomeController(time);

    controller.actuateLights(true, mockLight::turnOn, mockLight::turnOff);

    Assert.assertTrue(mockLight.turnedOn);
}

//用于测试
public class MockLight {

    boolean turnedOn;

    void turnOn() {
        turnedOn = true;
    }

    void turnOff() {
        turnedOn = false;
    }
}

现在，我们真正拥有了一个可测试的方法，它非常稳定、可靠，不必担心对系统产生副作用，同时我们也具有了清晰易懂、可读性强、可重用的api。

在函数式编程中，有一个概念叫纯函数，纯函数的主要特点是：

像这样的函数一般具有非常好的可测试性，对它做单元测试方便、且不会出问题，我们需要做的就只是传参数进去，然后检查返回结果。对于不纯的函数，例如某个函数 Foo() ，它依赖了一个有副作用的函数 Bar() ，那么 Foo() 也变成了一个有副作用的函数，最终，副作用可能会遍布整个系统。

参考资料：https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters