測試驅動實踐

wms3.0

的後台業務部分採用了測試驅動的開發方式。在開發過程中，對

pbunit

做了一次比較大的公升級，讓測試變得更容易和穩固。

在我們的

tdd中，與標準的

tdd還是有一些不同的，在此列出我們的

tdd過程： 1)

設計，定義介面 2)

測試概要設計：在

excel

中定義測試的場景、輸入、輸出、資料。此處的資料只定義主要的部分，對於與業務無關的，不定義。例如，序列號字段一般是不定義的 3)

測試詳細設計：在

pbunit

中將excel

中的資料維護進去。這裡的資料必須定義完全。例如序列號必須定義 4)

編寫業務類的框架**（也可以第

2步做） 5)

縮寫測試類和測試** 6)

執行測試，根據測試結果的指示編寫業務**，直到所有測試全部ok

與標準tdd

的區別： 1)

標準tdd

中，先編寫測試**再編寫業務**。我們反過來的主要原因是如果不寫業務框架**，測試**無法儲存（在其它開發工具中，只是編譯失敗，不影響儲存）。 2)

在標準tdd

中，強調小步前進，**是逐步完善的。而在我們的實踐中，很多情況下是一次完成。因為在我們的設計中，已經把業務類分解得比較簡單了，在測試設計的過程中，又充分考慮到了各種情況，所以業務**往往是一次搞定。但與

tdd的原則其實並不違背，如果情況複雜，我們也會小步前進，但我們不能為了「小步」而「小步」。

在實踐過程中，還發現需要注意： 1)

不能代替**審查。測試是不可能窮盡所有情況的，在有些情況下，白盒仍然是必不可少的。 2)

開發人員要有正確的目標。在

tdd中，開發完成的標準是通過測試。但這句話不能過死的去理解，我們的本質目標還是要正確的完成業務邏輯。開發人員需要了解需求、設計，測試文件能幫助你理解，但不能為了去湊測試結果而開發。 3)

不要先寫業務**，再寫測試**。理解了兩步測試設計後，寫業務**的條件確實成熟了。但我們仍然不建議先寫業務**，因為測試**是很簡單的，業務**往往比較複雜，應該先把簡單的做完，然後全部投入複雜的部分，而不是很投入複雜的部分，然後單或會想到還有簡單的沒有做。