前面幾篇文章，先介紹了user story，ATDD，接著提到了要透過BDD來當作ATDD與TDD之間的橋樑。

這篇文章則是要介紹一下，筆者習慣用的BDD工具：SpecFlow。（open source & BSD license）

藉由SpecFlow的輔助，讓讀者朋友可以快速的體會到，用DSL撰寫腳本的方式，進而使用TDD開始實作系統內容。

上一篇文章：[Day 23]BDD - Introduction
本系列文章專區
＠前言
之所以需要透過BDD的工具來輔助我們，是因為：

1. 只看用人話描述的腳本，離程式碼太遙遠了。
2. 只看程式碼，則太技術面了。

透過BDD來結合這兩個部分，讓中間轉換的成本可以降的更低，並且讓使用者、開發人員、測試人員使用的基底一致。

＠SpecFlow

1. SpecFlow是一套open source，且under在BSD license。
2. 可直接在Visual Studio Gallery 上安裝add-in
3. 專案若需參考到SpecFlow的組件，則可以直接透過NuGet來下載。
4. 若想了解原始碼，則可以到Github上下載。

相關網址：

1. 官網
2. Visual Studio Gallery: SpecFlow
3. Document
4. github

這邊附上官網對SpecFlow的介紹：

SpecFlow also supports the concepts of Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD), which are often used synonymously with Specification-By-Example.

讀者就不難了解，為什麼筆者會選用這一套工具了。

＠建立第一個 BDD 專案 with MS Test
官網的範例大部分都是使用 NUnit 來示範，甚至預設也是使用 NUnit 的設定，所以我就不對 NUnit 的設定多做介紹。這一篇文章要介紹，怎麼透過 MS Test 來進行 BDD 的測試。

當安裝完成後，請新建立一個『測試專案』，例如 TestAtmOperation：

＠建立 SpecFlow Feature File
如果您已經有安裝好 SepcFlow ，那麼在測試專案上，新增一個 item ，即可看到多出了三個項目類型：

1. SpecFlow Event Definition
2. SpecFlow Feature File
3. SpecFlow Step Definition

這邊先選擇 SpecFlow Feature File ，並命名為 DrawMoney ，代表『提款』的 feature 。

接著在方案中就可以看到 DrawMoney.feature ，打開它之後，會看到預設的 template 內容：

接著，先新增放置 production code 的 Library，並在測試專案上，設定好參考。

接著給它勇敢的建置下去，碰！跳出 21 個錯誤，都是 DrawMoney.feature 找不到 NUnit 的錯誤。

＠安裝 NuGet Package Manager
這邊要先請各位安裝一下 NuGet Manager，一切會快樂很多。

＠加入 SpecFlow 參考
裝好之後，在測試專案的參考上，滑鼠右鍵，選擇『管理NuGet套件』

接著搜尋『SpecFlow』。

給它安裝下去。會看到參考中多了 TechTalk.SpecFlow ，而且多了 App.Config 檔案。

＠更改 SpecFlow 設定檔，改成 MS Test
打開App.Config，會看到 SpecFlow 的設定區塊已經加上去了， SpecFlow 很佛心地連 config 設定的網址都附上來了。

點 hyperlink 可以看到第一個區塊，就是跟我們說，怎麼將 unitTestProvider 設定成 MS Test 。當修改設定檔完成後， SpecFlow 會跳一個提示，問你是否要重新產生 feature 對應的測試程式，在這邊也就是我們的 DrawMoney.feature.cs 。按『是』就對了。

到這邊，基本上就設定完成了。

＠Run ! Test Run ! Test Run !
接下來跑一下測試，（我習慣的 hotkey 是 Ctrl+R, A），基本上我是拿執行單元測試來當作 build 用，以確保每次 build 程式碼除了符合編譯器規定，也能通過單元測試。

測試結果與相關訊息，如下圖所示：

測試結果出現了一個『結果不明』的狀態，這代表了 feature 檔，透過 DSL 所建立的 Unit Test 檔案內容中，相關的設定還沒初始化完成。

而在錯誤訊息中，出現了很有趣的東西，看到了嗎？

第一行的 Assert.Inconclusive，No matching step definition found for one or more steps ，代表測試過程中，已經透過 feature 檔所產生的測試程式，來尋找有沒有對應的 step 檔案。且後續的訊息更揭露了， step 檔案中，應該要有的 function 內容。而且這些內容與 feature 檔案的 Scenario 是相吻合的。

接下來，就是要滿足測試程式所期望的測試結果。

＠建立 SpecFlow Step Definition
剛剛的測試結果提醒我們， feature 沒有對應的 step 定義，所以接下來就新增一個 Spec Flow Step Definition ，取名為 DrawMoneyStep 。

該檔案預設的 template 內容如下，該有的說明也都在註解中了：

已經滿足了原本的測試結果，再跑一下測試。測試的結果仍然是『結果不明』，但細部資訊已經不同了。

到這邊為止，其實就是 BDD 的起手式完成了。

＠說明
回顧一下預設 Feature 檔案的內容：

Feature :
預設的 feature 檔案內容中， Feature 區段的意義：

1. 定義了一個『加法器』，也就是 Feature: Addition。這邊可以把 Feature 當作 User Story 的名稱。

2. In order to avoid silly mistakes：代表這個 User Story 的價值，也就是 Business Value。

3. As a math idiot：代表了 User Role 。

4. I want to be told the sum of two numbers：代表了目的，也就是 Goal。

Scenario :
而Scenario 的區段，就更直覺了：

1. Scenario: Add two numbers。代表這是一個描述『將兩個數字相加的 Scenario 』。

2. Given 關鍵字：可以當做環境設定，可以把它視為 3A 裡面的 Arrange 。

3. And 關鍵字：則用來連接上一個子句，以這邊的例子來說，就是環境設定包括了：『I have entered 50 into the calculator And I have entered 70 into the calculator』。

4. When 關鍵字：觸發的動作，可以把它視為 3A 裡面的 Act 。

5. Then 關鍵字：代表應該出現什麼結果，可以把它視為 3A 裡面的 Assert。

註：user story的部份，可以參考前面的文章：[Day 20]ATDD - User Requirement

雖然把 Scenario 中的關鍵字與 3A 原則（可以參考前面的文章：[Day 3]動手寫Unit Test）作結合，但不代表只有 Then 裡面，可以加上 Assert 。如果大家有用 DbC (Design by Contract) 的方式設計程式，就應該知道，在每一個步驟、環節，適當地透過 Assert 來檢查 Pre-Condition, Post-Condition（Pre-Condition, Post-Condition，很熟悉吧，請參考前面提到use case的部份，請見：[Day 20]ATDD - User Requirement），會讓程式碼更加健壯。

有了以上的概念，再來看預設的 Step 檔案內容，就不會太難懂了。

BDD 結束，接下來下一篇，我們來 TDD 吧！

＠小結
這篇文章只是快速簡單的介紹，該怎麼安裝SpecFlow，並針對最重要的兩種檔案：Feature與Step的內容作個說明。

簡單的說：

1. Feature檔，對應到user story
2. Feature檔中的scenario，則對應到acceptance test cases
3. Scenario中的Given, When, Then，則對應到單元測試的3A原則：Arrange, Act, Assert

最終型態應該是，Feature與Scenario即為系統開發的spec，開發人員只要依照這樣的spec完成功能，通過測試，即可驗收。

而這一份spec，測試人員與開發人員一定可以看懂，甚至於使用者也看的懂，因為是用DSL撰寫的。（甚至可以寫成中文）。

倘若透過一些設計與輔助，開發流程可以變成下面這樣：

1. 一開始的user story與acceptance test cases，可能可以透過Fit/FitNeese之類的工具，讓使用者透過熟悉的工具，如excel、wiki等介面來輸入user story與驗收測試案例

2. 接著再把這些資料轉換成feature與scenario

3. 再由開發人員依據BDD specflow透過T4產生的step template

4. 再依據step template，開始進行TDD，所有測試都是從使用者需求的系統行為驅動。

如此一來，就真的可以：

1. 把各角色、各階段的轉換成本降到最低
2. 大家也可以用同樣的語言溝通
3. 彼此的基底就是這些會說話的測試案例，以及隨時可以單鍵執行的測試程式。
4. 測試案例還可以當作是系統與物件的說明書
5. 需要接手、維護的人員，只要看的懂測試案例，就可以知道怎麼用。
6. 加上有豐富的測試程式保護，所以重構與需求異動時，不用擔心改這壞那的情況。

＠備註

1. 這篇文章先用預設的 Feature 與 Step 來設計『加法器』，請原諒我前面就把命名命成我下一篇要用的範例 >”<

2. SpecFlow 若要安裝1.9以上的版本，要先移除1.8的版本，如果讀者朋友之前已經裝過的話

3. 目前SpecFlow版本是1.9.1，筆者建議安裝1.9以上的版本。比1.8版本多了不少功能。不過，1.9.0的版本，在VS2012上，執行單一Scenario測試會有問題，是已經修復的bug，1.9.1版，是否可以在VS2012上正確執行無誤，筆者晚點會去測試看看，再跟大家回報。