靈活軟體開發——測試

Test-Driven Development 測試驅動開發

如果我們遵守了以下的規則進行開發，那麼這就是測試驅動開發：

1. 在編寫任何産品代碼之前先寫一個會運作失敗的單元測試。
2. 編寫一個單元測試，使其剛好能夠運作失敗或者編譯失敗。
3. 編寫的産品代碼應該剛好能夠使失敗的單元測試運作通過。

如果按照這種開發方式進行開發，那麼我們将處于一個非常短的開發周期中。這樣做的好處是，首先程式中的每一個單獨的功能子產品都經過測試來驗證它的功能。這些測試将作為未來開發的一個強有力的後盾，它保證我們的開發沒有破壞已有的功能。其次，測試先行的作法将使我們以一種調用者的角度來審視我們的程式。我們将關注子產品之間的接口設計，這使得我們設計的程式是可以被友善地調用的。此外，先寫測試的方法要求我們設計的程式是可測試的。對于軟體設計來說，可調用和可測試是十分重要的，為了達到這個目的，軟體必須要解耦。測試先行的另一個重要的作用是，這些測試可以作為一種文檔。如果你想知道如何調用一個函數或者建立一個對象，測試用例将告訴你如何去做。這樣的文檔是可編譯的可執行的。它永遠是最新的，而且不會說謊。

Test Isolation 測試促使子產品之間隔離

測試先行将使軟體被更好的解耦，通過接口和Mock對象來解除子產品與外界之間的依賴。

Serendipitous Decoupling 意外獲得的解耦合

單元測試将促使我們将子產品隔離，迫使我們從整個程式的結構角度來進行解耦。測試先行可以改善我們的設計。

Acceptance Tests 驗收測試

盡管單元測試可以驗證系統中的各個小部分可以如預期的運作，但是它無法驗證整個系統的行為和預期相符。單元測試就好像是白盒測試，來驗證系統的每個個體。驗收測試則是黑盒測試來驗證客戶的需求是否被滿足。

驗收測試是一個功能的最終文檔。一旦業務人員編寫了驗收測試來驗證該功能是正确的，那麼開發人員将可以通過這些驗收測試更真實地了解這些功能。正如同單元測試是系統内部子產品的可編譯和可執行的文檔，驗收測試是整個系統功能的可編譯和可執行的文檔。簡而言之，驗收測試是真正的需求文檔。

此外，編寫驗收測試将對整個系統架構有着深遠的影響。為了使整個系統可測試，它必須在更高的層次上解耦。

Serendipitous Architecture 意外獲得的架構