单元测试

一：何为单元测试

定义：单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。

单元测试从长期来看，可以提高代码质量，减少维护成本，降低重构难度。但是从短期来看，加大了工作量，对于进度紧张的项目中的开发人员来说，可能会成为不少的负担。

二：单元测试要写多细

单元测试不是越多越好，而是越有效越好！进一步解读就是哪些代码需要有单元测试覆盖：
1. 逻辑复杂的
2. 容易出错的
3. 不易理解的，即使是自己过段时间也会遗忘的，看不懂自己的代码，单元测试代码有助于理解代码的功能和需求
4. 公共代码。比如自定义的所有http请求都会经过的拦截器；工具类等。
5. 核心业务代码。一个产品里最核心最有业务价值的代码应该要有较高的单元测试覆盖率。

三：何时写单元测试

写单元测试的时机不外乎三种情况：

（1）一是在具体实现代码之前，这是测试驱动开发（TDD）所提倡的；

（2）二是与具体实现代码同步进行。先写少量功能代码，紧接着写单元测试（重复这两个过程，直到完成功能代码开发）。其实这种方案跟第一种已经很接近，基本上功能代码开发完，单元测试也差不多完成了。

（3）三是编写完功能代码再写单元测试。我的实践经验告诉我，事后编写的单元测试“粒度”都比较粗。对同样的功能代码，采取前两种方案的结果可能是用10个“小”的单测来覆盖，每个单测比较简单易懂，可读性可维护性都比较好（重构时单测的改动不大）；而第三种方案写的单测，往往是用1个“大”的单测来覆盖，这个单测逻辑就比较复杂，因为它要测的东西很多，可读性可维护性就比较差。

建议：我个人是比较推荐单元测试与具体实现代码同步进行这个方案的。只有对需求有一定的理解后才能知道什么是代码的正确性，才能写出有效的单元测试来验证正确性，而能写出一些功能代码则说明对需求有一定理解了。

四：为什么要写单元测试

（1）让我们对自己的代码有信心

修改了代码后单测依然通过的，起码说明我们的修改没有破坏程序的正确性。这从主观上能增加我们对代码的信心。虽然单元测试通过了并不意味着程序就没有bug了，但我们也要了解到这可能不是单元测试的问题。单元测试顾名思义是测试一个”单元”，这个”单元”一般是类或方法，而不是整个系统。对整个系统的测试那是集成测试，功能测试的职责。单元测试追求的是快速反馈，频繁执行。集成测试虽然测“全局”，但成本较高，所以执行频率较少。两者使用场景不同，目的不同。

如果你经常混github，你应该能够发现，很多开源的项目是具备详尽的单元测试的。 为什么呢？ 单元测试可以说是工程师对项目功能的承诺，别人查看测试代码，就能了解对应的函数的大概使用方法，什么样的输入会有什么输出，什么时候会报异常，都是有迹可循，看着很放心。如果你看到一个项目，没有测试，即使readme写的天花乱坠，你敢用到公司的项目中么？

（2）避免低级错误，为代码重构保驾护航，

看到代码很差劲，想重构，但又担心重构之后出问题，怎么办呢？如果有单元测试情况就不一样了，重构完代码，跑一遍单元测试，如果单元测试都通过，基本上可以保证我们的重构没有破坏原来代码逻辑的正确性。不过前提是之前的写的单元测试质量很好，覆盖率很高。当然这仅限于小范围的重构，比如重构一个类或者函数的实现，但对于大刀阔斧的重构（比如单体重构成微服务，面向库表模式重构成DDD），就不适用，那个时候要重写单元测试了。

（3）通过单元测试快速熟悉代码

单元测试不仅起到了测试的作用，还是一种很好的“文档”，通过单元测试，我们不需要深入的阅读代码，便能知道这段代码做什么工作，有哪些特殊情况需要考虑，包含哪些业务。

五：相关文档

现在大部分的测试教程都有一个通病，那就是用了大量的无意义的测试来举例讲解。这么做可以理解，毕竟教程的作者又不知道你的实际情况，为了浅显易懂起见，自然还是那些无意义的测试更容易看明白。我得承认真正学会写测试是需要时间来练习的，有些东西真是只可意会不可言传。对于初涉测试的程序员来说，那些教程里的无意义的例子的确容易给人一种错觉：如果实际工作中也要这么写测试的话实在是太啰嗦太繁琐了！没错，一开始是这样的。一你得坚持练习，二你得找对方法；测试是为“聪明的懒人”准备的玩具。

推荐两个东西，一个是 Gary Bernhardt 录制的一系列视频，大量的讲解了实际项目中的测试理论和技巧，都是干货没有无意义的东西，但是有难度，要反复多看多体会：https://www.destroyallsoftware.com/screencasts/catalog

还有一个是来自于现实世界中一个非常有名的例子，一群人利用测试和重构挽救了一个差点不可救药的经典项目 Redmine，之后他们为这次大规模的重构写了一本书：Refactoring Redmine，满满的都是经验值啊。