|
1、TDD 要求我们在编写生产代码前先编写单元测试。
三定律：
定律一?在编写不能通过的单元测试前，不可编写生产代码。
定律二?只可编写刚好无法通过的单元测试，不能编译也算不通过。
定律三?只可编写刚好足以通过当前失败测试的生产代码。
2、测试代码和生产代码一样重要。脏测试会让测试越变越糟，维护代价增大。故测试代码和生产代码一样重要。
测试带来一切好处
覆盖了生产代码的自动化单元测试程序组能尽可能地保持设计和架构的整洁。测试代码了一切好处，因为测试使改动变得可能。有了覆盖率高的测试，可以毫无顾虑地改进架构和设计。
3、在单元测试中，可读性甚至比在生产代码中还重要。测试如何才能做到可读？和其他代码中一样：明确，简洁，还有足够的表达力。在测试中，你要尽可能少的文字表达大量内容。
4、整洁的测试还遵循以下 5 条规则：
快速（Fast）?测试应该够快。测试应该能快速运行。测试运行缓慢，你就不会想要频繁地运行它。如果你不频繁运行测试，就不能尽早发现问题，也无法轻易修正，从而也不能轻而易举地清理代码。最终，代码就会腐坏。
独立（Independent）?测试应该相互独立。某个测试不应为下一个测试设定条件。你应该可以独立运行每个测试，及以任何顺序运行测试。当测试互相依赖时，头一个没通过就会导致一连串的测试失败，使问题诊断变得困难，隐藏了下级错误。
可重复（Repeatable）?测试应当可在任何环境中重复通过。你应该能够在生产环境、质检环境中运行测试，也能够在无网络的列车上用笔记本电脑运行测试。如果测试不能在任何环境中重复，你就总会有个解释其失败的借口。当环境条件不具备时，你就会无法运行测试。
自足验证（Self-Validating）?测试应该由布尔值输出。无论是通过或失败，你不应该查看日志文件来确定测试是否通过。你不应该手工对比两个不同文本文件来确认测试是否通过。如果测试不能自足验证，对失败的判断就会变得依赖主观，而运行测试也需要更长的手工操作时间。
及时（Timely）?测试应及时编写。单元测试应该恰好在使其通过的生产代码之前编写。如果在编写生产代码之后编写测试，你就会发现生产代码难以测试。你可能会认为某些生产代码本身难以测试。你可能不会去设计可测试的代码。
|