這是一篇用來分享 BDD 的 Survey

身為敏捷開發的愛好者，不可忘記這四條敏捷宣言：

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

第二條提到：「Working software over comprehensive documentation（可用的軟體重於詳盡的文件 ）」。如果「詳盡的文件」本身就是「可用的軟體」，那不是很多問題都解決了嗎？也就是說，如果能夠有一種紀錄需求文件方法，這種文件不但客戶看得懂，而且還可以執行，自動驗證需求與程式實作是否一致，那真的是太好了。

• From : http://teddy-chen-tw.blogspot.tw/2013/07/bdd1.html

以下是整個開發流程的相關環節，一環扣著一環：

• User Story：定義與管理使用者需求
• Acceptance Test Cases：定義 user story 的完成事項
• BDD 的 Feature 與 Scenario：描述 acceptance test cases 所對應的系統行為
• BDD 的 Step Template：用來放 TDD 的測試案例 
  進入 TDD 循環

• From : https://msdn.microsoft.com/zh-tw/library/dn308251.aspx

常用的 BDD 测试框架
Ruby 中的 Cucumber，Python 中的 Behave，Lettuce 及 Freshen，.Net 中的 SpecFlow 等。

• From : https://www.ibm.com/developerworks/cn/opensource/os-cn-bdd-web-ui-test/

Cucumber 的工作原理

First, the developers, testers and business folks explore the problem domain, and collaborate to produce concrete examples that describe the behaviour they want.
Sometimes that discussion is hard, because it throws up all the misunderstandings and assumptions you’d normally discover much later on.
But that’s a good thing.
Next, the team use Cucumber to run those examples as automated acceptance tests.
As the team work on the solution, Cucumber tells you which examples are implemented and working, and warns you about the ones that aren’t.
Before you know it, you have one document that’s both the specification and the tests for your software.

• From : http://webuild.envato.com/blog/making-the-most-of-bdd-part-1/