TDD让你的代码可扩展、可维护、可复用，有了测试你就不担心对代码的修改！没有测试，每次修改都可能带来缺陷。无论架构多有扩展性，无论设计划分得有多好，没有了测试，你就很难做改动，因为你担心改动会不会引入不可预知的缺陷。
TDD有三定律：
1）在编写不能通过的单元测试前，不可编写生产代码;
2）只可编写刚好无法通过的单元，不能编译也不算通过;
3）只可编写刚好足以通过当前失败测试的生产代码。
这三条定律将你限制在大概30少一个的循环中。测试与生产代码一起编写，测试只比生产代码早写几秒钟。
这样写程序，我们每天会编写数十个测试，每个月编写数百个测试，每年编写数千个测试。这样写程序，测试将覆盖所有生产代码。测试代码量足以匹敌生产代码量，导致令人生畏的管理问题。
为了避免这个问题，高质量的测试应如下：
1）测试代码和生产代码一样重要，测试代码的腐坏会直接导致生产代码的腐坏，要重视测试代码的质量。
2）整洁的测试有三个要素：可读性，可读性和可读性。
3）如何保持可读性呢？和函数一样，要保持代码的自我解释性，要简短，命名有意义，要有抽象分层。
4）每个测试应保持断言数最少，这点类似于函数的“只做一件事”。
5）快速，测试应该够快，如果不快，就不会让程序员愿意去使用它了。而测试的目标应该是提倡程序员频繁使用。
6）独立。测试与测试之间应该没有依赖，保持每个测试都是独立的。
7）可重复性。 测试应在任何环境都可以重复通过，让代码不过于有针对性，对环境产生依赖。
8）自足验证。 测试应该有布尔值输出，非常直观地反映测试是否通过。你不应该查看日志文件来确认是否通过测试，也不应该手工对比两个不同文本文件来确认是否通过测试，如果测试不能自足验证，对失败的判断就会变量依赖主观，而运行测试也需要更长的手工操作时间。
9）及时。 测试应及时编写。单元测试应该恰好在使其通过的生产代码之前编写。