文／刘冉

　　最近几年“TDD已死”的声音不断出现，特别是David Heinemeier Hansson那篇文章——引发了大量的讨论。其中最引人注目的是Kent Beck、Martin Fowler、David三人就这个举行的系列对话（辩论）——?

　　当前国内对TDD的理解十分模糊，大部分人也没有明确和有意识的去实施TDD，因此许多人对此都有着不同的理解。

　　其中最经典的理解就是基于代码的某个单元，使用Mock等技术编写单元测试，然后用这个单元测试来驱动开发，抑或是帮助在重构、修改以后进行回归测试。而现在大部分反对TDD的声音就是基于这个理解，比如：

工期紧，atv直播，时间短，写TDD太浪费时间；

业务需求变化太快，开奖，修改功能都来不及，根本没有时间来写TDD；

写TDD对开发人员的素质要求非常高，普通的开发人员不会写；

TDD 推行的最大问题在于大多数程序员还不会「写测试用例」和「重构」；

由于大量使用Mock和Stub技术，导致UT没有办法测试集成后的功能，对于测试业务价值作用不大

……

　　总结一下，技术人员拒绝TDD的主要原因在于难度大、工作量大、Mock的大量使用导致很难测试业务价值等。

　　这些理解主要是建立在片面的理解和实践之上，而在我的认知中，TDD的核心是：先写测试，并使用它帮助开发人员t来驱动软件开发。

　　首先是先写测试，这里的测试并不只是单元测试，也不是说一定要使用mock和stub来做测试。这里的测试就是指软件测试本身，可以是基于代码单元的单元测试，可以是基于业务需求的功能测试，也可以是基于特定验收条件的验收测试。

　　其次是帮助开发人员，主要是帮助开发人员理解软件的功能需求和验收条件，帮助其思考和设计代码，从而达到驱动开发的目的，所以。

　　ATDD（Acceptance Test Driven Development）：验收驱动测试开发，首先BA或者QA编写验收测试用例，然后Dev通过验收测试来理解需求和验收条件，并编写实现代码直到验收测试用例通过。

　　由于验收方法和类型也是多种多样的，所以根据验收方法和类型的不同，ATDD其实是包含BDD（Behavior Driven Development）、EDD（Example Driven Development），FDD（Feature Driven Development）、CDCD（Consumer Driven Contract Development）等各种的实践方法。

　　比如以软件的行为为验收标准，这个是BDD；如果以特定的实例数据为验收标准，这个是EDD；如果以Web Service API消费者提出API契约来驱动API提供者开发API，这个是CDCD等。所以ATDD的具体实现需要结合项目的实际情况来选用适合的验收测试方法与类型。

　　UTDD（Unit Test Driven Development）：单元驱动测试开发，首先Dev编写单元测试用例，然后编写实现代码直到单元测试通过。这个就是现在很多人所谓的TDD、实践的TDD、喜欢的TDD、抱怨的TDD，但是它却只是真正意义上TDD的一部分而已。

　　TDD金字塔

　　再来看看David 的，他主要是认为TDD大量使用mock，导致无法测试软件连接了数据库之后的功能，进而无法测试其业务价值。

　　其次他提出应该使用”Long live testing”, 而他并没有说明这种测试应该是在编写代码之前还是之后写，以及会不会用来作为客户对于软件的验收标准。如果他没有这样做，那他只是使用”Long live testing”来做回归测试；如果他做了，那么他也是使用了ATDD，从而使用了TDD。

　　所以他对TDD的理解还是狭隘的，认为TDD只是UTDD，导致他写了这篇文章来批评TDD。有可能他在现实工作中已经使用了ATDD，也就是TDD。

　　最后来看看Kent Beck、Martin Fowler、David关于的辩论，我觉得他们所说的都有道理，并且也是合理的。原因是他们的背景和行业不同，本来对于不同的行业和不同的背景就应该选择适合的测试驱动方法（有可能不一样）。

　　首先来看看Kent Beck，他在Facebook工作，出版过很多书，可以定位为一名在大型IT公司工作的软件思想家。其次是David，一个标准欧洲帅哥，ROR创造者之一，Basecamp公司的创始人和CTO，Basecamp是一个只有几十个人的小型软件公司，所以他可以定位是一名创业者、技术牛人。