「勿忘初心」TDD，Dont DDT

偶爾翻到自己五年前寫的關于TDD的文章，又看一遍， 感覺當時的自己是走在正確的路上。但是這么多年過去了，BDD也在流行，自己卻沒有一直沿著這條路走下去，為什么？ 老文重拾，感慨良多。

這個過程是我當時在用Ruby改造一個php的遺留系統，具體細節已遺忘。

正文

一直有個疑問，對于遺留系統，我們該如何TDD ？

我個人比較認同TDD是一種設計方法，不能代替真正意義上的測試。是幫助我們設計自己代碼的一種方法。對于遺留系統，面對一堆需求文檔，面對一陀陀已經難 以繼續維護的陳舊代碼，你的心是否哇涼哇涼的 ？做為一個使用Rails的開發人員，難道你要把這些代碼翻譯為Ruby代碼嗎 ？
答案當然是不！
很多時候，我們雖然很清楚要TDD，但是很多時候我們是在DDT?；旧鲜歉鶕z留系統的代碼把功能代碼寫的差不多了，才想起來寫測試。寫完之后， 用流行的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