TDD三定律和5条规则

1. 三定律

1. 定律一：在编写不能通过的单元测试前，不可编写生产代码
2. 定律二：只可编写刚好无法通过的单元测试，不能编译也算不通过
3. 定律三：只可编写刚好足以通过当前失败测试的生产代码

通俗来讲，以上三定律对应如下

1. 没有用例失败前，不要写生产代码
2. 如果有用例失败，那就不要继续编写新的失败用例；当有用例失败，应该去修改生产代码，而不是继续编写用例
3. 仅写能通过当前失败用例的代码，不写跟当前失败用例不相关的代码，但是可以重构

2. 5条规则：F.I.R.S.T.

1. 快速Fast：测试应该快，也就是执行时间短，能够快速运行。如果执行慢，就不会想要频繁执行；不频繁执行，就不能尽早发现问题；不能尽早发现问题就不能轻易修正，因为发现问题时已经编写了很多了
2. 独立Independent：测试应该相互独立。某个测试不应为下一个测试设定条件。你应该能够独立的运行每一个测试，及以任何顺序运行测试。当测试互相依赖时，头一个没通过就会导致一连串的测试失败，使问题诊断变得困难，隐藏了下级错误
3. 可重复Repeatable：测试应该可以在任何环境下执行通过。你应该可以在生产环境、验证环境中重复运行测试，也可以在无网络的环境下使用本地进行测试。如果测试不能在任意环境中运行测试，你就总会有个解释失败的借口；或者当环境条件不具备时无法运行测试
4. 自足验证Self-Validating：测试应该有布尔值输出。无论是通过还是失败，你不应该通过查看日志文件来确认测试是否同哟。你不应该手工对比两个不同文本文件来确认测试是否通过。如果测试不能自足验证，对失败的判断就会变的依赖主观而运行测试也需要更长的手工操作时间
5. 及时Timely：测试应该及时编写。单元测试应该恰好在使其通过的生产代码之前进行编写。因为如果在编写生产代码之后进行测试，你会发现生产代码难以测试。你可能会认为某些生产代码本身难以测试。你可能不会去设计可测试的代码。