TDD好处在哪？是否与自动测试好处混淆

TDD是测试驱动开发，简单理解就是先写测试后写代码。测试case必然是TDD的副产品。传统的瀑布开发模型，是先写代码再写测试。两者开发方式不一样，但是最终都会留下测试集。能自动运行的产品代码测试集就是对于新增代码或重构代码的保护。所以如果只是简单看是否有自动测试集保护代码这个角度来说，保证代码重构，并不是TDD测试现行的独有好处。

那TDD的好处在哪？这个问题把它转化成先写测试的好处在哪？

现有测试会帮助程序员写的代码具备可测试性，这个是天然自带的好处。用TDD方式写代码，程序员没写一段代码的目的就是去pass测试case。一旦测试case pass了。就应该停止写代码，再去写下一个测试case，如此循环。每段代码都可以被测试，自然就有了天然可测试性。

TDD开放方式能让程序员在写代码时候做出好的设计的决定。我是这样理解的，第一测试先行，代码没有的时候，写测试case的依据是什么？只有需求文档。如果后写测试，程序员不仅开需求，而且还会多少受到自己代码影响。即便发现代码有架构上的问题，是否会写出低质量的测试case来为不改架构妥协呢？这样的事情是屡见不鲜的，有些时候不是程序员愿意留一堆烂摊子在那里。而是项目的进度赶在程序员跑。

其次程序员还有一种“快意代码”的情况，也就是写代码是件很爽的事情，有时候对需求还不是很搞得很清楚的时候，就迫不及待动手写代码了。有时候代码写的意犹未尽，代码实现了需求不需要的功能，过度开发了。先写测试case从流程上帮助程序员在写代码前，更深入地搞清楚需求。

第三测试先行会让程序员的代码更加松耦合。每个测试case的目的是相对容易写得比较清晰的。而写代码写得松耦合就需要一定功底。如果写一个测试case然后写一段代码，就自然让这段代码的目标比较单一，只是为pass这个case，减少了代码的辅助逻辑。

TDD是一种灰盒测试，它不像传统的基于function的白盒测试，它只测试对外接口。测试现行迫使程序员率先关注它的对外接口，这就让程序被设计得更加便于调用。

TDD的模式是每个程序员前一分钟的代码是可以运行的。这样就大大减少了程序员debug时间。试想如果程序员开发了几日的代码，做系统调试，是不是会花不少时间debug问题。如果一分钟前程序员的代码是可以运行的，是不是很容易找到这一分钟内的新代码问题？

与TDD对应的模型是DLP Debug Later Programming. TDD的模式不是简单的Coding after Test Case，而是Red-Green-Refactor。注意前两步只是完成了TDD少部分工作，Refactor是更花时间的工作。完整的TDD在第一时间里就完成了局部的重构，减少了技术债务堆积问题。