最近看了幾篇關於測試驅動開發的文章，簡單總結下：
TDD的基本思路就是通過測試來推動整個開發的進行，但測試驅動開發並不只是單純的測試工作，而是把需求分析、設計、質量控制量化的過程。說白了就是在開發功能代碼之前，先編寫測試代碼，然後只編寫使測試代碼通過的功能代碼，從而以測試來驅動整個開發過程的進行。
1.在開始工作前，由業務分析人員，測試人員，開發人員進行一次討論，就驗收條件達成一致並形成記錄,這樣可以避免測試和開發人員理解不一致現象出現。
2.根據某一個具體的需求列一個TODO-list出來，以提醒我們需要做哪些事情，它將使我們始終保持注意力集中，同事它也可以告訴我們什麼時候可以完工。如果我們想起其他要做的測試，就加如清單。
3.新增一個測試,根據需求編寫一個測試用例
4.運行所有的測試程序（有時候只需要運行一個或一部分），並失敗；由於此時與測試相關的具體功能的類、函數等還沒有開發，所以肯定會失敗。
5.做一些小小的改動，這些改動其實只編寫使測試能夠通過的代碼（沒必要實現具體的功能代碼細節），此時是儘快地讓測試程序可運行，爲次可以在程序中使用一些不合清理的方法。
6.運行所有的測試，並且全部通過
7.重構代碼，以消除重複設計，優化設計結構
TDD原則
獨立測試：不同代碼的測試應該相互獨立，一個類對應一個測試類（對於C代碼或C++全局函數，則一個文件對應一個測試文件），一個函數對應一個測試函數。用例也應各自獨立，每個用例不能使用其他用例的結果數據，結果也不能依賴於用例執行順序。 一個角色：開發過程包含多種工作，如：編寫測試代碼、編寫產品代碼、代碼重構等。做不同的工作時，應專注於當前的角色，不要過多考慮其他方面的細節。
測試列表(前面建立的to-do list)：代碼的功能點可能很多，並且需求可能是陸續出現的，任何階段想添加功能時，應把相關功能點加到測試列表中，然後才能繼續手頭工作，避免疏漏。
測試驅動：即利用測試來驅動開發，是TDD的核心。要實現某個功能，要編寫某個類或某個函數，應首先編寫測試代碼，明確這個類、這個函數如何使用，如何測試，然後在對其進行設計、編碼。
先寫斷言：編寫測試代碼時，應該首先編寫判斷代碼功能的斷言語句，然後編寫必要的輔助語句。
可測試性：產品代碼設計、開發時的應儘可能提高可測試性。每個代碼單元的功能應該比較單純，“各家自掃門前雪”，每個類、每個函數應該只做它該做的事，不要弄成大雜燴。尤其是增加新功能時，不要爲了圖一時之便，隨便在原有代碼中添加功能，對於C++編程，應多考慮使用子類、繼承、重載等OO方法。
及時重構：對結構不合理，重複等“味道”不好的代碼，在測試通過後，應及時進行重構。
小步前進：軟件開發是複雜性非常高的工作，小步前進是降低複雜性的好辦法。軟件功能越複雜，這個步伐應該越小，在開始下一個工作之前，一定要保證前面已經完成的功能正確無誤的可執行。