Kent Beck所在的公司开发的是大型复杂业务软件（Facebook平台），代码量巨大，需要长时间（几年）大量人员（几十甚至几百）来开发和维护。DHH开发的中小型企业软件（比如CRM），代码量一般，需要快速（几个月）、少量人员（几个到十几个）开发和维护。

　　Kent Beck在金钱和人力资源相对充足、时间相对充裕的情况下追求的是代码质量，大量人员的良好协作与平台稳定。DHH却在金钱和人力资源相对较少情况下追求最大化客户业务价值，使得少量人员能快速开发出软件并卖给客户赚钱。

　　所以在Kent Beck所在的环境下，单元测试（UTDD）是非常有价值的；而在DHH所在的环境下，功能测试或者ATDD却更为适合。

　　国内很多人对于TDD的狭隘理解还源于很多网上的中文资料，百度百科对于的解释就是其中一个：

　　“TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。”

　　而国外有不少站点上的资料是对于TDD是有正确理解的，比如下图是一个。从其中的“We take a test-driven development(TDD) approach”和”We take a TDD approach at the requirements level”就能发现其对TDD的理解就是包含UTDD和ATDD。

　　TDD不是银弹，不要期望它能轻易解决你的问题，无论是UTDD、EDD还是BDD，根据自己项目的实际情况，比如资金、人力资源、时间、组织架构等，合理的选择。

　　今天我们又聊了聊TDD，也希望大家重新理解一下，重新思考和尝试一下，然后你会发现另外一片云彩。

　　TDD并没有死，死的是你的持续学习、思考、实践与总结。当前国内很多软件开发人员对于TDD的理解比较模糊，大部分人也没有明确和有意识的去实施TDD，因此很多人都有着不同的理解。