第九章 单元测试
测试驱动开发。敏捷和TDD运动鼓舞课许多程序员编写自动化单元测试。
9.1 TDD三定律
定律一在编写不能通过的单元测试前，不可编写生产代码。
定律二只可编写刚好无法通过的单元测试，不能编译也算不通过
定律三只可编写刚好足以通过当前失败测试的生产代码。
9.2 保持测试整洁
测试代码和生产代码一样重要。它可不是二等公民。它需要被思考、 被设计和被照料。它该像生产代码一般保持整洁。
如果测试不能保持整洁，你就会失去它们。没有了测试，你就会失去保证生产代码可扩展的一切要素。你没看错。正是单元测试让你的代码可扩展、可维护、可复用。原因很简单。 有了测试，你就不担心对代码的修改！没有测试，每次修改都可能带来缺陷。
9.3 整洁的测试
测试代码也是需要可读性的。明确、简洁、足够的表达力。
每个测试都需要分成三个环节：第一个环节构造测试数据，第二个环节操作测试数据，第三个部分检验操作是否得到期望的结果。
9.3.1 面向特定领域的测试语言
代码清单9-2中的测试展示了为测试构造一种面向特定领域的语言的技巧。我们没有直 接使用程序员用来对系统进行操作的API,而是打造了一套包装这些API的函数和工具代码， 这样就能更方便地编写测试，写出来的测试也更便于阅读。
9.3.2 双重标准
测试和生产确实应该用两套不同的标准。毕竟他是在测试环境运行。着两种环境有不同的需求。
9.4 每个测试一个断言
有个流派认为，JUnit 中每个测试函数都应该有且只有一个断言语句.好处是这些都归结为一个可快速方便地理解的结论。
每个测试一个概念，就不会有长代码的测试用例。
9.5 F.I.R.S.T
整洁的测试还遵循以下5条规则，
- 快速(Fast)测试应该够快。测试应该能快速运行。
- 独立((Independent )测试应该相互独立。某个测试不应为下一个测试设定条件。
- 可重复(Repeatable )测试应当可在任何环境中重复通过。
- 自足验证(SelValidating )测试应该有布尔值输出。
- 及时(Timely )测试应及时编写。单元测试应该恰好在使其通过的生产代码之前编写。
9.6 小结
如果你坐视测试腐坏，那么代码也会跟着腐坏。保持测试整洁吧。
