TDD 的簡介 http://www.agiledata.org/essays/tdd.html
TFD(Test first design) 的步驟
(1) 先快速加入一個測試, 基本上是足夠讓程式不能運作就可以
(2) 接下來執行你的測試, 已確定這個新增的測試會失敗
(3) 然後開始修改你的程式碼, 讓他可以通過你新增的測試
(4) 接著再重新執行你的測試. 如果失敗就在修改程式, 直到你通過測試為止.
(5) 如果成功之後, 再回步驟(1)重新再開始一個功能. (你可能會先需要refactor排除一些duplication or debt)
作者會覺得TDD應該是
TDD = Refactoring + TFD
TDD完全會傳統開發方法相反. 當你開始去實做一個新功能, 第一個問題你要問的就是, 目前的設計是否是最佳的設計, 可以讓你去實作這個功能. 如果是, 你就開始用TFD去進行. 如果不是, 先用refactor去改變一些會受到新功能影響的設計, 讓你能很容易新增新功能. 因此你總是在改進你設計的品質, 讓它在未來時仍可以很容易地運作.
當程式開發人員談到TDD的方法時, 它會說在沒有產生一個失敗的測試之前, 是無法寫新的功能, 因為這個功能還沒有出現. 事實上,在沒有任何測試建立前, TDD 程式設計師是不會寫任何一行code的. 聽起來這個原則很簡單, 但是當你第一次使用, 通常需要很大紀律, 因為你很容易跳過這個步驟, 而直接開始撰寫你所想要的功能. 所以搭檔編程(pair programming)的另一個好處, 是幫助你確保不會偏離軌道.
此外, TDD一個潛在的假設, 是要有一個unit testing framework可以使用. 雖然目前也有一些商業化的工具可以使用, Agile軟體開發人員通常會使用xUnit家族系列的工具, 像是JUnit, VBUnit等. 不過若是沒有這樣的工具, 基本上TDD幾乎是不可行的.
Kent Back在2000年時開始推廣extreme programming, 並且在2003年對TDD定義了兩個簡單的規則:
1. you should write new business code only when an automated test has failed
2. you should eliminate any duplication that you find
Kent解釋說為什麼這兩個rules會產生複雜的行為:
- 你的設計會自然因為程式碼的運行, 而提供你決策所需的回饋
- 自己寫自己的測試, 因為你不會想為了要別人來幫你寫測試, 你需要一天等個20次.
- 你的開發環境必須對很多小的改變, 提供快速反應.(例如, 你需要更快的compiler, regression test suite也要run的更快)
- 你的設計必須具有高度的內聚力和鬆弛的耦合力的元件, 來讓測試容易進行(這同時也讓將來的開展或是維護會容易點)
對於開發人員, 其含義是他們需要學習如何撰寫有效的單元測試. 根據Beck的經驗, 好的單元測試應該是
- 執行的很快(短的啟動時間, 安裝時間, 以及結束時間)
- 可以獨立執行 (你應該能夠重新安排執行順序)
- 使用的資料可以讓你容易閱讀和了解
- 如果有需要的話, 可以使用真實的資料(例如: 複製production的資料)
- Represent one step towards your overall goal
留言列表
