在敏捷和devops領域，企業越來越關注持續整合和持續部署問題。他們更頻繁地更新軟體，給軟體測試造成額外的時間壓力。而測試驅動開發可以成為解決這個問題的一劑良方。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
測試驅動開發（test-driven development, tdd）是一種開發方法，即在開發階段使用自動化測試。與傳統的開發方法相比，乙個很大的區別是tdd要求你在開發之前先編寫測試。
\u0026#xd;\n\u0026#xd;\n
tdd似乎只與軟體測試有關，但這並不是它的最終目的。tdd的目標是通過自動化的方式來演化系統，以滿足所有的功能和非功能性需求。
\u0026#xd;\n\u0026#xd;\n
經常會被提及的另乙個術語是kiss原則。kiss是「keep it ******, stupid」或「keep it ****** and straightforward」的縮寫。這個原則的核心思想是盡可能用最少的精力來解決給定的問題（或挑戰）。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
要正確使用tdd方法，最好先搭建乙個初始的軟體架構。我說的不一定是巨集偉的架構設計，但至少是乙個粗略的架構。
\u0026#xd;\n\u0026#xd;\n
當然，也要看你都做了哪些架構決策。在某些情況下，你不想編寫單元測試，因為它會降低**的質量，或者測試用例太過複雜。你可以改為編寫自動化的場景或整合測試。關鍵是要對它們進行自動化。在以下步驟中，我假設它們是單元測試。
\u0026#xd;\n\u0026#xd;\n
確定合理的測試用例;\u0026#xd;\n\t
確定測試條件;\u0026#xd;\n\t
編寫乙個骨架類（只有方法簽名），讓**可以通過編譯;\u0026#xd;\n\t
編寫測試**;\u0026#xd;\n\t
執行測試（它應該會失敗）;\u0026#xd;\n\t
花最少的工作量讓測試用例可以執行;\u0026#xd;\n\t
執行自動化測試;\u0026#xd;\n\t
重構**;\u0026#xd;\n\t
再次執行自動化測試，保證軟體仍然可以正常執行;\u0026#xd;\n\t
重複，直到符合產品待辦事項（使用者故事）的驗收標準。\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n
第一步是確定要編寫的第乙個測試是什麼，你需要考慮到依賴關係。首先，你要實現你所依賴的變更。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
乙個單元測試由三部分組成：arrange、act和assert。為了確保只實現所需的內容，你要知道方法的前置和後置條件。
\u0026#xd;\n\u0026#xd;\n
比如有這樣的乙個使用者故事：
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n作為使用者，我只想安排沒有衝突的預約，這樣就不會讓客戶失望。
\u0026#xd;\n
在這個使用者故事中，使用者只想要沒有衝突的預約。有五種情況可能會讓新的預約產生衝突。
\u0026#xd;\n\u0026#xd;\n
在進行單元測試期時，你檢查所有這些條件，以及方法的預期結果。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
這一步並不是正式tdd的乙個步驟，不過這樣做可以給我們帶來方便，因為後續我們就可以利用**自動完成。
\u0026#xd;\n\u0026#xd;\n
你將建立乙個類（如果它是新的）和它的方法，但先不要實現任何功能**。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
現在可以編寫實際的測試**了，可以遵循arrange、act、assert這樣的結構。
\u0026#xd;\n\u0026#xd;\n
arrange：設定環境（如樁和測試資料），這樣就可以斷言你的測試方法。\u0026#xd;\n\t
act：呼叫方法！\u0026#xd;\n\t
assert：檢查結果、樁等等。\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n
執行之前建立的測試，預期的結果是測試無法通過。如果它執行成功了，你必須回到第4步。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
接下來是**時間！但是有乙個問題，你必須用盡可能少的**讓測試執行通過。
\u0026#xd;\n\u0026#xd;\n
對於第2步中的預約使用者故事，還沒有用於檢查錯誤日期的測試，這就是為什麼之前先不實現它。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
寫完**並通過測試後，就可以再次執行所有的自動化測試。新增加的**不應該破壞已有的構建或導致其他測試失敗。
\u0026#xd;\n\u0026#xd;\n
如果出現其他測試失敗，請務必做出修改，讓所有測試可以再次通過。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
在執行完所有的自動化測試（全部通過）之後，可以開始對**進行重構了。
\u0026#xd;\n\u0026#xd;\n
這次應該把重心放在**質量上。檢查**是否符合編碼指南和規範，刪除重複的**，在不清晰的地方新增注釋。另外，新增用於生成文件的注釋。
\u0026#xd;\n\u0026#xd;\n
還有一點不要忘了，看看當前的解決方案是否仍然是能夠解決問題的最簡單的解決方案。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
再次執行所有測試，確保在重構**後所有測試仍然可以通過。
\u0026#xd;\n\u0026#xd;\n
如果在**重構後有測試失敗，就要做出必要梗概，再次讓所有測試都通過。
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
在前面的步驟中，你可能一次實現了乙個或多個方法。在這一步，你需要驗證是否滿足產品待辦事項或使用者故事所指定的驗收標準。
\u0026#xd;\n\u0026#xd;\n
如果符合驗收標準，那麼你的任務就完成了。如果沒有，請從頭開始重複所有步驟。
\u0026#xd;\n\u0026#xd;\n
檢視英文原文：
\u0026#xd;\n\u0026#xd;\n
感謝張嬋對本文的審校。
在敏捷中應用測試驅動開發
在敏捷和devops領域，企業越來越關注持續整合和持續部署問題。他們更頻繁地更新軟體，給軟體測試造成額外的時間壓力。而測試驅動開發可以成為解決這個問題的一劑良方。測試驅動開發 test driven development,tdd 是一種開發方法，即在開發階段使用自動化測試。與傳統的開發方法相比，乙...
在敏捷中應用測試驅動開發
在敏捷和devops領域，企業越來越關注持續整合和持續部署問題。他們更頻繁地更新軟體，給軟體測試造成額外的時間壓力。而測試驅動開發可以成為解決這個問題的一劑良方。測試驅動開發 test driven development,tdd 是一種開發方法，即在開發階段使用自動化測試。與傳統的開發方法相比，乙...
在敏捷中應用測試驅動開發
在敏捷和devops領域，企業越來越關注持續整合和持續部署問題。他們更頻繁地更新軟體，給軟體測試造成額外的時間壓力。而測試驅動開發可以成為解決這個問題的一劑良方。測試驅動開發 test driven development,tdd 是一種開發方法，即在開發階段使用自動化測試。與傳統的開發方法相比，乙...