理解TDD

本文的目的是以最精炼的语言，正解什么是TDD，为什么要TDD，和TDD的难点。

什么是TDD？

简单的说，TDD = 测试先行(TFD, Test First Development) + 重构(Refactoring) + 回归测试(Regression Test)。


如果要实现某个功能，TDD要求在初步定义完这个功能的外部接口之后，先根据这个功能的用例写测试代码(黑盒测试)，测试代码检验的是这个功能的外部接口的使用场景，而非具体的实现细节。然后，才是实现这个功能的这些外部接口，在实现的过程中，同时还会根据需要写一些单元测试，一般单元测试测试的不仅仅是外部接口，还包括实现的内部细节(白盒测试)。关于单元测试的更多讨论，请参考： UnitTesting。如果发现这些外部接口设计得有问题，则需要进行修改和重构。每次代码修改之后，或者增加新功能之前，都需要回归运行已有的所有测试(不仅仅是测试先行的这些测试，还包括所有的单元测试)。

测试先行保证了功能的所有使用场景的逻辑性和完备性；重构则在保证功能语义的前提下，尽可能安全的改进设计和实现；回归测试则保证了任何修改不破坏任何已有的功能，这样开发人员就能放心大胆地专注于实现或改进眼前的功能。这样无疑既提高了开发人员的信心和工作效率，而且时刻保证了功能的完整性和代码的正确性。

如果对TDD详细的前世今生感兴趣，请参考： TDD on WikiPedia

为什么TDD？

TDD最大的好处是时刻确保了每次添加或修改任何代码的过程中，对任何已有的功能都是安全的。尤其是对于编译和回归测试的运行时间较短的情况下，有大牛甚至建议每新增或修改超过10行可运行的代码，就运行一次回归测试。这样不仅仅能确保你写的每一行代码的正确性，而且，基本可以避免使用单步调试来发现问题，因为，问题往往就应该在最新的这10多条代码上。

TDD的另一个好处是，相对于几十页上百页的天知道和什么年代的代码同步的技术文档来说，TDD的测试代码因为描述的就是功能的实际使用场景，并且和代码一定是实时同步的，对开发人员来说，它其实是一种既准确，又易于理解，易于维护的“技术文档”。

TDD的难点

• 并非所有类型的代码都适合TDD，尤其是那些不能由机器简单的判断对错的情形，比如图形UI和数据库设计。
• TDD需要让管理层意识到TDD的价值，为TDD预留额外的开发时间，并且强制每个开发人员按TDD的流程来写代码，需要自上而下的管理和开发流程的支持。
  

英文资料

• http://en.wikipedia.org/wiki/Test-driven_development
• http://www.agiledata.org/essays/tdd.html
• http://codebetter.com/blogs/jeremy.miller/archive/2006/03/31/142091.aspx
• http://c2.com/cgi/wiki?TestDrivenDevelopment