測試驅動開發的基本過程如下：
1） 明確當前要完成的功能。可以記錄成乙個 todo 列表。
2） 快速完成針對此功能的測試用例編寫。
3） 測試**編譯不通過。
4） 編寫對應的功能**。
5） 測試通過。
6） 對**進行重構，並保證測試通過。
7） 迴圈完成所有功能的開發。
測試隔離。不同**的測試應該相互隔離。對一塊**的測試只考慮此**的測試，不要考慮其實現細節（比如它使用了其他類的邊界條件）。一頂帽子。開發人員開發過程中要做不同的工作，比如：編寫測試**、開發功能**、對**重構等。做不同的事，承擔不同的角色。開發人 員完成對應的工作時應該保持注意力集中在當前工作上，而不要過多的考慮其他方面的細節，保證頭上只有一頂帽子。避免考慮無關細節過多，無謂地增加複雜度。
測試列表。需要測試的功能點很多。應該在任何階段想新增功能需求問題時，把相關功能點加到測試列表中，然後繼續手頭工作。然後不斷的完 成對應的測試用例、功能**、重構。一是避免疏漏，也避免干擾當前進行的工作。
測試驅動。這個比較核心。完成某個功能，某個類，首先編寫測試**，考慮其如何使用、如何測試。然後在對其進行設計、編碼。
先寫斷言。測試**編寫時，應該首先編寫對功能**的判斷用的斷言語句，然後編寫相應的輔助語句。
可測試性。功能**設計、開發時應該具有較強的可測試性。其實遵循比較好的設計原則的**都具備較好的測試性。比如比較高的內聚性，盡 量依賴於介面等。
及時重構。無論是功能**還是測試**，對結構不合理，重複的**等情況，在測試通過後，及時進行重構。關於重構，我會另撰文詳細分 析。
小步前進。軟體開發是個複雜性非常高的工作，開發過程中要考慮很多東西，包括**的正確性、可擴充套件性、效能等等，很多問題都是因為複雜 性太大導致的。極限程式設計提出了乙個非常好的思路就是小步前進。把所有的規模大、複雜性高的工作，分解成小的任務來完成。對於乙個類來說，乙個功能乙個功能 的完成，如果太困難就再分解。每個功能的完成就走測試**－功能**－測試－重構的迴圈。通過分解降低整個系統開發的複雜性。這樣的效果非常明顯。幾個小 的功能**完成後，大的功能**幾乎是不用除錯就可以通過。乙個個類方法的實現，很快就看到整個類很快就完成啦。本來感覺很多特性需要增加，很快就會看到 沒有幾個啦。你甚至會為這個速度感到震驚。（我理解，是大幅度減少除錯、出錯的時間產生的這種速度感）
測試用例的編寫就用上了傳統的測試技術。操作過程盡量模擬正常使用的過程。
全面的測試用例應該盡量做到分支覆蓋，核心**盡量做到路徑覆蓋。
測試資料盡量包括：真實資料、邊界資料。
測試語句和測試資料應該盡量簡單，容易理解。
為了避免對其他**過多的依賴，可以實現簡單的樁函式或樁類（mock object）。
如果內部狀態非常複雜或者應該判斷流程而不是狀態，可以通過記錄日誌字串的方式進行驗證。
關於測試驅動開發的思考
關於測試驅動開發的思考 測試驅動開發 test driven develop 作為敏捷思想的重要組成部分，將開發和測試在同一時段完成，我認為是乙個很不錯的想法，尤其是經歷了無數測試後的返工以及開發中的疏漏後，測試驅動開發將作為以後開發工作中首當其衝的選擇。據我所知，這裡有幾個誤區需要糾正，其一 敏捷...
測試驅動開發
測試驅動開發 test driven development,英文縮寫tdd 是極限程式設計的乙個重要組成部分，它的基本思想就是在開發功能 之前，先編寫測試 也就是說在明確要開發某個功能後，首先思考如何對這個功能進行測試，並完成測試 的編寫，然後編寫相關的 滿足這些測試用例。然後迴圈進行新增其他功能...
測試驅動開發
在開發的過程中，總有種憂慮感，擔心系統會出現這樣或那樣的bug，修改bug後，更要把所有的流程重測一遍。於是我們在完成 後，編寫測試程式，將所有的流程通過測試程式自動跑一遍。測試驅動開發就在這種需求下誕生了。它將測試用例的開發提到了功能 之前，這樣功能 是為滿足測試用例能通過而開發，同時，測試用例也...