由於公司要實現TDD形式的開發，所以准備了一下，准備在后續的項目中，投入到TDD的懷抱中。
在找一些參考書目的過程中，偶遇《測試驅動開發的藝術》這本書，書中的編碼為JAVA派系，但是書的內容卻是通俗易懂，書的作者屬於實戰派的寫手，所以一開始幾章就直接上具體的例子，然后通過測試，開發，重構，測試，開發，重構。。。的過程來展示如何實踐TDD的。
在看書的過程中，我逐漸對TDD有了新的認識，目前已經看到了第三章，通過之前作者的引導，我所理解的TDD是這樣的：
TDD，測試驅動開發，是一種軟件開發過程的實踐，是一種理念，而非實現的工具。它要求軟件開發者在開發軟件的過程中，按照 測試，開發，重構，測試，開發，重構。。。。的過程，來一點一滴的構建軟件的。
映射到我以前的設計工作中，我確實體會到了TDD所帶來的便捷之處：
以前的開發：瀑布式的開發，先寫功能代碼，遇到編譯錯誤的地方，就直接Debug項目，然后讓其編譯通過即可，沒有真正的去檢測功能是否是正常的；即便有時候去寫一寫測試用例，也只是針對核心的業務邏輯進行一下覆蓋，沒有涉及到重構，測試的過程，所以有時候在開發完畢，發現問題還是挺多的。
TDD的開發：先寫失敗的測試，然后修改讓其通過測試，然后實現功能代碼，然后測試，然后重構，然后再測試，再開發，再重構。。。反正就是保證自己每次寫的功能點都是可用的，都是通過測試的。等軟件正式交付以后，所有的這些測試就可以當做以后系統出現問題時候的檢測依據，可以很方便的定位到出錯點。如果項目非常大的時候，能夠快速的定位到出錯點是非常難能可貴的。（在以前花旗做軟件的時候，有一個巨大的項目，核心邏輯用c++寫，表現層用C#寫，粘合層用的CLR c++寫，項目中的線程特別多，有時候當表現層出錯的時候，需要定位到出錯的地方，需要從C#調試到CLR C++，然后再往Native C++調試，過程苦不堪言，最重要的是，整個項目編譯一次，需要四五個小時。。。熬過這段時間，才知道TDD的這種機制的重要性，作者的感受，於我心有戚戚焉。致敬。）
但是TDD也不是萬能的，TDD能幫我們寫出運行良好的軟件，不過我們還是要想辦法保證交付的功能正好能滿足客戶的需求。這里我們涉及到了“驗收測試驅動開發”這個詞，咱們且看且走。