BDD（17）Given-When-Then怎麼寫？

March 13 10:48~11:46

 

兩種寫法

在BBD中Given-When-Then格式被經常用來撰寫例子，撰寫的方式可分為兩大類：

• Imperative：命令式，一步一步寫出使用者護系統互動的詳細步驟。
• Declarative：宣告式、聲明式，著重在於使用者「做什麼」（What）而不是「怎麼做」（How）。

採用何種方式，對於可執行規格（executable specification）或驗收測試的可維護性有著很大的影響。在《Cucumber BDD How-to》書中有一個例子。

Imperative Step

Scenario: Write blog

Given I am on the blog homepage

When I click “New Post” link

And I fill “My first blog” as Title

And I fill “Test content” as content

And I click “Post” button

Then I should see the blog I just posted

相對於命令式的寫法，宣告式的寫法如下：

Declarative Step

Scenario: Write blog

Given I am on the blog homepage

When I write a new blog post

Then I should see the blog I just posted

***

有何差異？

採行BDD一般來說會推薦說使用宣告式的寫法，因為這種方法可以隱藏更多的實作細節，除了可讀性比較高以外，還可以更專注於描述系統行為而非系統如何實作。宣告式的作法會把實作細節放在測試自動化層，也就是Cucumber的step definition裡面。如此一來如果實作細節改變，例如網頁介面連結名稱改變，也不需要修改規格（不需要修改Cucumber的.feature檔案）。

命令式的方式也不是完全沒有好處，雖然採用命令式寫法很可能被使用者介面給綁架，但在某些情況之下命令式的寫法會比宣告式的寫法來的清楚。重點還是在於：

• 清楚表達系統行為而非系統實作
• 當實作方式改變時應該不需要修改系統規格，只需修改實作程式碼與測試自動化程式

***

小心怪味道

有一些鄉民在採行BDD的初期為了減少撰寫自動化驗收測試的時間，會等程式都寫好之後用「capture and replay」（擷取畫面，重複撥放）的工具來產生驗收測試案例。這種做法不能算是BDD，因為並沒有做到「測試先行」，也就是開發流程並沒有先撰寫一個失敗的驗收測試案例，而是反過來先寫production code，再用「capture and replay」的方式產生自動化驗收測試。

這種方式所產生的驗收測試，極度依賴於使用者介面，只要介面一修改，驗收測試往往也需要跟著修改，導致很高的維護成本，最終可能讓開發人員無以為繼，不想繼續維護大量與使用者介面緊密相關的驗收測試。

稍微好一點的，會先用Given-When-Then寫scenario，但很可惜寫出的例子也是從使用者介面思考，依然會造成不易維護的問題。這些都是在落實BDD的初期很容易發生的現象，也是要做好BDD需要突破的一個重要關卡。

***

友藏內心獨白：寫Use Case也不應該有太多介面細節。