偶尔翻到自己五年前写的关于TDD的文章，又看一遍， 感觉当时的自己是走在正确的路上。但是这么多年过去了，BDD也在流行，自己却没有一直沿着这条路走下去，为什么？ 老文重拾，感慨良多。

这个过程是我当时在用Ruby改造一个php的遗留系统，具体细节已遗忘。

正文

一直有个疑问，对于遗留系统，我们该如何TDD ？

我个人比较认同TDD是一种设计方法，不能代替真正意义上的测试。是帮助我们设计自己代码的一种方法。对于遗留系统，面对一堆需求文档，面对一陀陀已经难 以继续维护的陈旧代码，你的心是否哇凉哇凉的 ？做为一个使用Rails的开发人员，难道你要把这些代码翻译为Ruby代码吗 ？
答案当然是不！
很多时候，我们虽然很清楚要TDD，但是很多时候我们是在DDT。基本上是根据遗留系统的代码把功能代码写的差不多了，才想起来写测试。写完之后， 用流行的rcov测试一下测试代码覆盖率，不足的地方再加上测试 ？ 回头想想，我们引入TDD的初衷是这样的吗 ？ 大家都心知肚明，并不是这样的！
重新思考TDD之后，我决定在现做的这个ticket里完全采用了TDD的方式去开发，今天一天下来，感触颇深：
1。 昨天拿到php源码，一看代码，了不得啊，和我功能相关的源码文件之有三个，但代码却有三千多行。我该怎么办 ？我肯定不可能把那三千多行都看完吧。我该如何TDD ？
T代表Test，测试驱动开发，很显然，是先有测试，要不谈何驱动开发。 但是没有功能代码，你测试什么呀？ 既然TDD是一种设计方法，那么这个测试，代表的应该是你大脑中对这个功能的自我认知。 如果对需求了解不清楚，你是没有办法对这个功能产生自我的认知的。硬着头皮整理了一下需求文档，在脑中形成一个大概的轮廓之后，就可以动手写测试了。此功 能是要生成一个报表，就是一个create -> show 的过程。一般人想到的先是页面，我是一般人，所以我也是从页面开始的，根据已经明确的需求写下自己对这个页面的幻想：

因为51cto的代码格式问题，

更详细的点击：原文地址： http://tao.logdown.com/posts/158033-do-not-forget-the-chuxin-tdddont-ddt