讀書摘要: 測試是最好的需求敘述
Test Driven Practical TDD and Acceptance TDD for Java Developeres - Lasse Koskela, Chapter 2
很多人認為只要需求寫完整, 或是有寫需求, 自然就可以做出客戶所要的系統.
但是, 事實上, 常常在最後時, 客戶很驚訝地說, 為何你會做成這樣.
因此在agile中, 期待以測試先行, 以測試個案為例子, 來說明我們想開發的系統, 到底長得怎樣.
例如, 我們要開發一個mail template的子系統. 也就是系統有一個要寄的郵件內容樣板, 樣板中有些變數, 可以動態改變這些變數值, 來產生要寄出的郵件內容.
例如: "Hi {$Name} How are you?", 若是我們給$Name的值是David, 最後的輸出就是: "Hi David How are you?"
當開發人員在開發時, 我們會把需求轉換成任務(task), 像是
- 定義一個正規表示式, 來表達樣板中的內容
- 寫一個parser, 來處理這個正規表示式
- 寫一個template engine, 來提供一組API, 讓外界使用parser的功能
...
這裡就是傳統開發方法的第一個陷阱: 任務完成了, 我們無法知道功能是否完成, 因為任務完成, 和原先的需求, 之間沒有任何關連性.
有些人可能會覺得, 我們所列的任務太粗了, 或者說需求描述得太簡略. 那我們把它拆解成下面的敘述如何呢?
- 系統可以在運行時, 提供變數的值.
- 若是其中有個變數, 沒有設定其值就要顯示, 便會產生錯誤
- 樣板中的變數值, 可以支援多國語系
- 樣板中的敘述, 可以支援多國語系
...
大家應該會覺得好多了, 可是你還是很難確認, 例如樣板內只能有一個變數呢? 還是可以有多個變數? 若是變數沒有值時, 要顯示甚麼錯誤訊息? 上面的敘述便沒有說明.
因此, agile希望能更進一步地, 說明想要實作, 想要交付的系統是甚麼. 提出了以測試來表達我們想要做的需求是甚麼:
- 對於樣板"Hi {$Name} How are you?", 當$Name的值為David時, 樣板的內容輸出為"Hi David How are you?"
- 對於樣板"Hi {$Name} {$greeting}", 當$Name的值為David, 而$greeting為How are you時, 樣板的內容輸出為"Hi David How are you?"
- 對於樣板"Hi {$Name} How are you?", 當$Name沒有相對應的值時, 應顯示Missing Value Error的錯誤訊息
- 對於樣板"Hi {$Name} How are you?", 當$Name的值為David, 而使用輸入$ABC這個不存在的變數值為xxxx時, 樣板的內容輸出為"Hi David How are you?"
...
這樣你是否比較能安心呢? 是否當開發人員時做完時, 你比較能確定沒問題?
不過這個測試列表永遠不會結束, 它是一個活的文件. 每當你持續建構這個系統, 你便會增加新的測試.
留言列表
