1、編寫測試代碼
2、運行測試用例，發現用例不通過
3、增加少量實現代碼
4、運行測試用例，用例通過
5、重構
其中有三個比較關鍵的因素：測試、節奏、驅動。
測試驅動開發首先要講的就是測試了。以前在一個項目中，我需要寫一個帶有非常復雜業務的計算類。當時對于能否寫出來完全沒有信心，主要是情況太復雜，分支特別多。其中涉及到表達式的解析，自定義變量的引用關系，數據的匯總計算等。這時候如果采用傳統的開發方式是很難保證代碼的正確性，糟糕的情況就是在后臺計算類中的Bug只有在界面部分才能測試出來。后來決定采用測試驅動開發的方式，先構造用例，然后寫實現代碼。一方面可以從用例的角度分析這個模塊的功能，更重要的另外一個方面可以確保計算類的低Bug率。
在有了測試代碼的基礎上，在去實現這樣的需求心里是更加有底氣的。并且檢查復雜的程序內部邏輯比檢查一個個的測試用例要復雜得多。
重構是建立在擁有測試代碼的基礎上的。
節奏確定了效率。從上面介紹的測試驅動開發的五步中可以明確地看到一種節奏感。如果使用現在流行的測試框架，如：XUnit，在運行的時候可以看到“紅綠交替”的現象。（紅色代表用例未通過、綠色代表用例通過）。并且上面說的五步循環的時間非常短，往往以分鐘為單位衡量。
有了一個好的節奏，可以有力地支撐結對編程的實踐。
結對編程的概念很容易理解：兩個人共用一臺計算機編寫代碼。但實踐的時候會遇到很多問題。
以前在做結對編程的時候出現兩個人不“合拍”的情況。表現就是一個人在寫代碼，另外一個人在“思考”或者“發呆”。有的時候是覺得其中一個寫代碼寫累了，再換成另外一個�；蛘呖偸且粋�人在寫代碼，另外一個在旁輔導。
TDD中有一個節奏的問題。一個任務被分解成“紅條”、“綠條”的交替。結對的兩個人注意力全部放在“紅綠交替”上。這樣可以確保兩個人的步調一致，雙方都知道現在我們做到了第幾步。通�？梢砸粋�人編寫測試用例，另外一個人實現，然后交換。
怎樣編寫讓對方出錯的用例，怎樣不讓自己的代碼有漏洞。開發就在這種合作、競爭的互動游戲中進行。
體會到了測試與節奏帶來的好處之后，最近發現TDD與簡單設計也有著比較緊密的關系。
如果能真的做到“驅動”這個效果，不編寫任何一行測試用例不需要的冗余代碼，在沒有用例證明的情況下不做結構上的設計。這樣將未做的工作最大化的藝術就是簡單設計的核心。
并不是說不需要設計，而是說設計的意圖必須要有相應的用例證明。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
