偶爾翻到自己五年前寫的關於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