整洁代码之道 9 单元测试

测试是简单的驱动式程序，让我们能够手工与自己编写的程序交互

9.1 TDD 三定律

1. 在编写不能通过的单元测试前，不可编写生产代码
   • 从测试的角度考虑代码实现
2. 只可编写刚好无法通过的单元测试，不能编译也算不通过
3. 只可编写刚好足以通过当前失败测试的生产代码

9.2 保持测试整洁

1. 测试必须随生产代码的演进而修改
2. 测试代码和生产代码一样重要
3. 单元测试让代码可扩展、可维护、可复用

9.3 整洁的测试

1. 在单元测试中，代码的可读性非常重要
2. 比较好的单元测试应该呈现出 构造-操作-校验（ BUILD-OPERATE-CHECK ） 的模式

9.3.1 面向特定领域的测试语言

1. 守规矩的开发者会将他们的测试代码重构为更简洁和具有表达力的形式

9.3.2 双重标准

1. 测试 API 中的代码和生产代码相比，存在不同的衡量标准
2. 测试代码应该简单、精悍、具有表达力，同时和生产代码一样有效
3. 测试代码只需要在测试环境中运行，和生产环境存在本质的区别
4. 所以可以为特定场景编写一些特定代码以满足测试条件

9.4 每个测试一个断言

1. 每个测试最后都需要有一个可快速方便理解的结论
2. 每个测试都只能有一个断言，未免显得过于绝对，应该是每个测试的断言数量都应该最小化
3. 或者说每个测试都应该只测试一个概念
4. 最终结论：每个测试都应该尽可能减少断言数量，同时一个测试只允许测试一个概念

9.5 F.I.R.S.T

1. 快速（ Fast ） ，测试应该够快
2. 独立（ Independent ） ，测试应该相互独立
3. 可重复（ Repeatable ） ，测试应该可以再任何环境中重复通过
4. 自足验证（ Self-Validation ） ，测试应该有布尔值的输出
5. 及时（ Timely ） ，测试应及时编写

9.6 小结

1. 对于项目的健康程度，测试和生产代码一样重要
2. 测试的存在，保证和增强了生产代码的可扩展性、可维护性和可复用性