补充单元测试你知道如何开始吗？

草帽路飞UU

单元测试应该及时编写，就算没有实践TDD，也应该在代码实现之后尽快编写单元测试，避免写出不可测试的代码，也可以让bug尽早暴露。
　　但很不幸的，我们很多时候在刚开始卓越工程，推广单元测试的时候，不得不面对补充单元测试的情况；这绝对是一个有挑战的事情。

　　补充单元测试应该从哪里开始？参考测试金字塔，对于基础组件库来说，可以根据具体情况来定。

　　对于业务库来说，第一步建议从金字塔顶端的测试：

　　·优先覆盖回归测试用例中P0级别的用例；

　　· 避免过度指定的端到端测试；

　　· 适当的契约测试；

　　接下来，从金字塔中间层开始，不断向上、向下补充。

　　可测试的设计
　　应当容易、快速地为一段代码编写单元测试；可测试的设计，使我们写出模块化的设计。

　　行动指南

　　为了写出可测试的代码，需要注意以下几点：

　　1、避免复杂的私有方法；

　　2、避免final方法；

　　3、避免static方法；

　　4、使用new要当心；

　　5、避免构造函数中包含逻辑；

　　6、避免单例；

　　7、组合优于继承；

　　8、避免服务查找；

　　9、基于接口的设计；

　　可测试的代码是否违背了SOLID中的开闭原则？

　　可测试的代码设计，有的时候需要避免复杂的私有方法或者受保护的方法，因为这些意味着不可测试。

　　这样的话是不是意味着可测试的设计违反了开闭原则呢？

　　在代码重构的时候，可以认为给对象模型增加了另外一种最终用户——测试用户。

　　另外如果一部分代码实在不希望暴露，也可以使用@visibleForTesting 修饰。

　　单元测试与重构

　　写单元测试的过程往往伴随着重构；代码重构同样需要单元测试保证代码正确运行。

　　重构需要遵守的纪律：无测试重构无意义，频繁重构、果断重构、坚决重构。

　　持续重构

　　将麻烦扼杀在摇篮。

　　果断重构

　　敏捷编程的名言之一。规则很简单：重构时要勇敢。勇敢尝试，勇敢修改，不用害怕代码。

　　让测试始终能通过

　　建一个绿色安全区，不允许破窗出现。

　　留条出路

　　仓库打好tag，以便在需要的时候能够回滚。

　　可测试的代码

　　可测试的代码就是解耦了的代码；可测试的代码帮助我们实现更好的抽象。

　　做不到TDD，可以做到测试先行

　　下图是遵循TDD三大法则的实践过程；TDD很强大，但不一定适用所有的团队，推广难度很大，学习曲线很高。



TDD事实上由两个方面组成：测试先行，以及演进式设计；测试先行是非常重要的工程实践，做不到TDD，可以做到测试先行。

　　在Kent Beck的经典名著《解析极限编程》中，提到：尽早测试，经常测试，自动测试！

　　测试先行的本质能力要求是接口的设计能力——能否清晰的定义出设计单元的边界。

　　如何理解单元测试代码覆盖率

　　不要把它们变成管理的指标。

　　这就是你使用覆盖率数字的目的：使用它们作为衡量标准来帮助你改进，而不是用它们作为惩罚团队和使构建失败的棍棒。 ——《匠艺整洁之道》

　　代码覆盖率的一大忌讳：为了追求代码覆盖率，只测试不进行验证；

　　一味追求代码覆盖率，往往写出无效的单元测试，额外增加了维护成本，最终不得不放弃以失败告终。

　　与其追求代码覆盖率，不如将重点关注在确保写出有意义的测试。

　　沉淀最佳实践

　　必须承认单元测试有一定的成本，成本曲线来看，前期比较高；恰恰是这前期的门槛，让很多人望而却步。在团队内推广的时候，最难的就是写出第一个单元测试；

　　我们需要沉淀最佳实践，帮助降低写单元测试的成本，让我们更容易地写出有效的单元测试。

　　我觉得沉淀最佳实践最好的方法，就是Code Review；正如我们前面所说的，要把单元测试当成是“一定公民”，在Code Review的过程中，互相学习、分享最佳实践，消除无效的单元测试。

　　隔离单元测试与集成测试

　　集成测试是对一个工作单元进行的测试，这个测试对被测试的工作单元没有完全的控制，并使用该工作单元一个或多个真实依赖，例如时间、网络、数据库、线程或随机数生成器等。

　　任何测试，如果它的运行速度不快，结果不稳定，或者要用到被测试单元的一个或多个真实依赖，就是集成测试。

　　在日常开发过程，我们需要建一个绿色安全区：单元测试与集成测试隔离；

　　集成测试不够稳定，运行时间长等问题，如果不做隔离，日常开发浪费时间和精力维护，最后导致开发人员不再信任测试。

　　单元测试与ABTest

　　单元测试与ABTest有什么关系吗？事实上没有什么关系。但一定程度程度上，它们本质是相同的，都是保障线上代码质量（当然单测的成本，对于基建、开发者的能力的要求更高）；


　　在日常开发中，经常主动为新的代码逻辑增加AB开关，一旦线上出问题留一条后路；发生问题的时候往往感慨AB开关救我一命；

　　单元测试可以让问题左移，防止问题上线，同样是一道保护；

　　如果有一天团队同学愿意主动增加单元测试来保护自己的代码，那么单元测试这件事就算比较成功了。