第 9 章 单元测试
本章介绍一些保持软件边界整洁的实践手段和技巧。
9.1 TDD 三定律
TDD 要求我们在编写生产代码前先编写单元测试。
三定律：
定律一 在编写不能通过的单元测试前，不可编写生产代码。
定律二 只可编写刚好无法通过的单元测试，不能编译也算不通过。
定律三 只可编写刚好足以通过当前失败测试的生产代码。
9.2 保持测试整洁
测试代码和生产代码一样重要。脏测试会让测试越变越糟，维护代价增大。故测试代码和生产代码一样重要。
测试带来一切好处
覆盖了生产代码的自动化单元测试程序组能尽可能地保持设计和架构的整洁。测试代码了一切好处，因为测试使改动变得可能。有了覆盖率高的测试，可以毫无顾虑地改进架构和设计。
9.3 整洁的测试
整洁的测试有什么要素？有三个要素：可读性，可读性和可读性。在单元测试中，可读性甚至比在生产代码中还重要。测试如何才能做到可读？和其他代码中一样：明确，简洁，还有足够的表达力。在测试中，你要尽可能少的文字表达大量内容。
9.3.1 面向特定领域的测试语言
不直接使用程序员用来对系统进行操作的 API，而是打造了一套包括这些 API 的函数的工具代码，这样就能更方便地编写测试，写出来的测试也更便于测试。
面向特定领域（我理解为测试）的语言的技巧是：测试代码呈现构造-操作-检验（BUILD-OPERATE-CHECK）模式。每个测试都清晰地拆分为三个环节。第一个环节构造测试数据，第二环节操作测试数据，第三部分检验操作是否得到强的结果。
9.3.2 双重标准
测试 API 中的代码与生产代码相比，的确有一套不同的工程标准。测试代码应当简单、精悍、足具表达力，但它该和生产代码一般有效。毕竟它是在测试环境而非生产环境中运行，这两种环境有着截然不同的需求。
有些事你大概永远不会在生产环境中做，而在测试环境中做却完全没有问题。通常这关乎内存或 CPU 效率（在生产环境不会做，但在测试环境中做却没有问题，因为不会影响测试环境的整洁）的问题，不过却永远不会与整洁有关。
9.4 每个测试一个断言
单个断言是个好准则，但是当一个以上断言的前提条件相同，非要遵守单个断言的准则，就会有重读的代码，所以单个测试中的断言数量应该最小化。
每个测试一个概念
每个测试函数中只测试一个概念。
最佳规则是尽可能减少每个概念的断言数量，每个测试函数只测试一个概念。
9.5 F.I.R.S.T.
整洁的测试还遵循以下 5 条规则：
快速（Fast） 测试应该够快。测试应该能快速运行。测试运行缓慢，你就不会想要频繁地运行它。如果你不频繁运行测试，就不能尽早发现问题，也无法轻易修正，从而也不能轻而易举地清理代码。最终，代码就会腐坏。
独立（Independent） 测试应该相互独立。某个测试不应为下一个测试设定条件。你应该可以独立运行每个测试，及以任何顺序运行测试。当测试互相依赖时，头一个没通过就会导致一连串的测试失败，使问题诊断变得困难，隐藏了下级错误。
可重复（Repeatable） 测试应当可在任何环境中重复通过。你应该能够在生产环境、质检环境中运行测试，也能够在无网络的列车上用笔记本电脑运行测试。如果测试不能在任何环境中重复，你就总会有个解释其失败的借口。当环境条件不具备时，你就会无法运行测试。
自足验证（Self-Validating） 测试应该由布尔值输出。无论是通过或失败，你不应该查看日志文件来确定测试是否通过。你不应该手工对比两个不同文本文件来确认测试是否通过。如果测试不能自足验证，对失败的判断就会变得依赖主观，而运行测试也需要更长的手工操作时间。
及时（Timely） 测试应及时编写。单元测试应该恰好在使其通过的生产代码之前编写。如果在编写生产代码之后编写测试，你就会发现生产代码难以测试。你可能会认为某些生产代码本身难以测试。你可能不会去设计可测试的代码。
9.6 小结
测试保证和增强了生产代码的可扩展性、可维护性和可复用性。保持测试的整洁，让测试具有表达力并短小精悍。