补充单元测试你知道如何开始吗？
单元测试应该及时编写，就算没有实践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开关救我一命；
单元测试可以让问题左移，防止问题上线，同样是一道保护；
如果有一天团队同学愿意主动增加单元测试来保护自己的代码，那么单元测试这件事就算比较成功了。
页:
[1]
