《測試驅動的嵌入式C語言開發》——3.7節測試驅動開發者的狀态機

3.7　測試驅動開發者的狀态機

可以把tdd想象成在一個狀态機（state machine）裡工作，就如圖3-2所示。在這一過程的每一步中，你隻需關注解決一個具體的問題。首先，你要決定下一個增量的行為是什麼并用測試表達你所期望的産出。然後你要滿足編譯的要求，也就是設計接口并讓頭檔案和測試之間達成一緻（有時你所選擇的名字已經在其他地方用過了，你會在這一步中發現這類問題）。

在接口和測試之間達成一緻後，預期會得到一個連結錯誤，之後就要增加一個骨架實作，但并不期望它是正确的實作。測試失敗是一個好的信号，說明你的測試可以發現代碼中的錯誤。如果你發現你本來預期得到一個測試失敗但它卻通過了，那可能表明測試中有錯誤。這在通過剪切複制上一個測試來寫下一個測試時很常見。并且，在用unity或者其他需要多個步驟來安裝測試用例的自動化單元測試架構時，失敗的測試會告訴你測試已經被正确地安裝到測試容器中了。

一旦測試通過，你就知道你已經擁有了期望的行為了，但你的工作還沒有完成。我們要留下幹淨的代碼。當努力使測試通過時，做得亂一點沒有關系。隻是不要把這些很亂的東西留在那裡——要對它進行重構。

為什麼要做這些小的步驟？因為它們讓我們每次都隻關注解決一個問題。