测试不要名不副实
避免测试的描述与测试内容不符；测试结果必须精准；测试该失败的时候一定要失败！
测试私有或者受保护的方法
解决思路：
- 将方法变成公共方法；
- 将方法抽取到新类；
- 将方法变成静态方法；
- 将方法成为测试可见方法；
避免强制的测试顺序
依赖测试顺序导致测试可靠性变得脆弱，未来维护成本变高；
清理测试环境
在teardown阶段清理测试环境，例如还原全局的Config、清理创建的文件目录等等；
统一的单测命名、变量命名
统一的单测命名可以提高可读性、可维护性；
使用有意义的断言
断言的错误信息要有意义，出现问题能够明确错误的原因；
把单元测试视为”一等公民”
测试用例应该被视为”一等公民”：同样需要代码评审，同样需要代码质量检查，确保单元测试的有效性；
单元测试代码评审的过程，也是团队同学互相学习的过程，沉淀最佳实践的过程。
加速执行速度
日常对单测执行时间进行监控，对测试进行性能分析，优化执行时间过长的测试用例。
测试金字塔
测试金字塔是Mike Cohn在他的著作《Succeeding with Agile》一书中提出了这个概念。测试金字塔是一个比喻，它告诉我们要把软件测试按照不同粒度来分组。它也告诉我们每个组应该有多少测试。
为了维持金字塔形状，一个健康、快速、可维护的测试组合应该是这样的：写许多小而快的单元测试。适当写一些更粗粒度的测试，写很少高层次的端到端测试。注意不要让你的测试变成冰淇淋或者沙漏那样子，这对维护来说将是一个噩梦，并且跑一遍也需要太多时间。
避免测试重复
在实现测试金字塔时，你也应该牢记这两条基本法则：
1.如果一个更高层级的测试发现了一个错误，并且底层测试全都通过了，那么你应该写一个低层级测试去覆盖这个错误；
2.竭尽所能把测试往金字塔下层赶；
如果你已经在低层级测试里覆盖了所有情况，那么再维护一个高层级的测试就没有必要了。警惕沉没成本的思维陷阱，果断摁下删除键。没有理由在不再提供价值的测试上浪费宝贵时间。
补充单元测试应该从哪里开始
单元测试应该及时编写，就算没有实践TDD，也应该在代码实现之后尽快编写单元测试，避免写出不可测试的代码，也可以让bug尽早暴露；
但很不幸的，我们很多时候在刚开始卓越工程，推广单元测试的时候，不得不面对补充单元测试的情况；这绝对是一个有挑战的事情。
补充单元测试应该从哪里开始？参考测试金字塔，对于基础组件库来说，可以根据具体情况来定；
对于业务库来说，第一步建议从金字塔顶端的测试：
-
优先覆盖回归测试用例中P0级别的用例；
-
避免过度指定的端到端测试；
-
适当的契约测试；
接下来，从金字塔中间层开始，不断向上、向下补充；
可测试的设计
应当容易、快速地为一段代码编写单元测试；可测试的设计，使我们写出模块化的设计；
行动指南
为了写出可测试的代码，需要注意以下几点：
- 避免复杂的私有方法；
- 避免final方法；
- 避免static方法；
- 使用new要当心；
- 避免构造函数中包含逻辑；
- 避免单例；
- 组合优于继承；
- 避免服务查找；
- 基于接口的设计；
可测试的代码是否违背了SOLID中的开闭原则？
可测试的代码设计，有的时候需要避免复杂的私有方法或者受保护的方法，因为这些意味着不可测试；
这样的话是不是意味着可测试的设计违反了开闭原则呢？
在代码重构的时候，可以认为给对象模型增加了另外一种最终用户——测试用户。另外如果一部分代码实在不希望暴露，也可以使用@visibleForTesting 修饰；
单元测试与重构
写单元测试的过程往往伴随着重构；代码重构同样需要单元测试保证代码正确运行。
重构需要遵守的纪律：无测试重构无意义，频繁重构、果断重构、坚决重构；
持续重构
将麻烦扼杀在摇篮；
果断重构
敏捷编程的名言之一。规则很简单：重构时要勇敢。勇敢尝试，勇敢修改，不用害怕代码。
让测试始终能通过
建一个绿色安全区，不允许破窗出现。
留条出路
仓库打好tag，以便在需要的时候能够回滚。
可测试的代码
可测试的代码就是解耦了的代码；可测试的代码帮助我们实现更好的抽象。
做不到TDD，可以做到测试先行
下图是遵循TDD三大法则的实践过程；TDD很强大，但不一定适用所有的团队，推广难度很大，学习曲线很高。
TDD事实上由两个方面组成：测试先行，以及演进式设计；测试先行是非常重要的工程实践，做不到TDD，可以做到测试先行。
在Kent Beck的经典名著《解析极限编程》中，提到：尽早测试，经常测试，自动测试！
测试先行的本质能力要求是接口的设计能力——能否清晰的定义出设计单元的边界。
如何理解单元测试代码覆盖率
不要把它们变成管理的指标。
这就是你使用覆盖率数字的目的：使用它们作为衡量标准来帮助你改进，而不是用它们作为惩罚团队和使构建失败的棍棒。 ——《匠艺整洁之道》
代码覆盖率的一大忌讳：为了追求代码覆盖率，只测试不进行验证；
一味追求代码覆盖率，往往写出无效的单元测试，额外增加了维护成本，最终不得不放弃以失败告终。
与其追求代码覆盖率，不如将重点关注在确保写出有意义的测试。
沉淀最佳实践
必须承认单元测试有一定的成本，成本曲线来看，前期比较高；恰恰是这前期的门槛，让很多人望而却步。在团队内推广的时候，最难的就是写出第一个单元测试；
我们需要沉淀最佳实践，帮助降低写单元测试的成本，让我们更容易地写出有效的单元测试。
我觉得沉淀最佳实践最好的方法，就是Code Review；正如我们前面所说的，要把单元测试当成是”一定公民”，在Code Review的过程中，互相学习、分享最佳实践，消除无效的单元测试。
隔离单元测试与集成测试
集成测试是对一个工作单元进行的测试，这个测试对被测试的工作单元没有完全的控制，并使用该工作单元一个或多个真实依赖，例如时间、网络、数据库、线程或随机数生成器等。
任何测试，如果它的运行速度不快，结果不稳定，或者要用到被测试单元的一个或多个真实依赖，就是集成测试。
在日常开发过程，我们需要建一个 绿色安全区：单元测试与集成测试隔离；
集成测试不够稳定，运行时间长等问题，如果不做隔离，日常开发浪费时间和精力维护，最后导致开发人员不再信任测试。
单元测试与ABTest
单元测试与ABTest有什么关系吗？事实上没有什么关系。但一定程度程度上，它们本质是相同的，都是保障线上代码质量（当然单测的成本，对于基建、开发者的能力的要求更高）；
在日常开发中，经常主动为新的代码逻辑增加AB开关，一旦线上出问题留一条后路；发生问题的时候往往感慨AB开关救我一命；
单元测试可以让问题左移，防止问题上线，同样是一道保护；
如果有一天团队同学愿意主动增加单元测试来保护自己的代码，那么单元测试这件事就算比较成功了。
写在最后
从软件工程到卓越工程，单元测试从可选变成了必要；想要实现主干开发、大库模式，单元测试是前提条件。
关于单元测试这件事，我觉得最重要永远是写单元测试的人，优秀的团队文化非常重要，没有什么能够真正衡量单元测试做的好坏，有的只是程序员的职业操守。
我们花了很大的篇幅讨论有效单元测试的重要性以及如何写出有效的单元测试，不得不承认单元测试有一定的成本，真正实践依然需要很多的路要走，需要我们在实践中定义好单元测试的边界，找到最适合团队的最佳实践。
参考文档
- 《单元测试的艺术》
- 《有效的单元测试》
- 《Succeeding with Agile》
- 《匠艺整洁之道》
- The Test Pyramid：https://martinfowler.com/articles/practical-test-pyramid.html
- Software Engineering at Google：https://qiangmzsx.github.io/Software-Engineering-at-Google/#/zh-cn/Chapter-12_Unit_Testing/Chapter-12_Unit_Testing
Original: https://www.cnblogs.com/88223100/p/How-to-write-effective-unit-tests.html
Author: 古道轻风
Title: 如何写出有效的单元测试
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/585412/
转载文章受原作者版权保护。转载请注明原作者出处！