【翻譯稿】Behavior Driven Development (BDD)行為驅動開發

這是一篇翻譯稿，方便給不知道BDD的同學掃盲。原文連結：What is BDD (Behavior Driven Development)? | Agile Alliance

Definition定義

Behaviour Driven Development (BDD) is a synthesis and refinement of practices stemming from Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD). BDD augments TDD and ATDD with the following tactics:

行為驅動開發 (BDD) 是對源自測試驅動開發 (TDD) 和驗收測試驅動開發 (ATDD) 的實踐的整合和改進。 BDD 通過以下策略增強 TDD 和 ATDD：

Apply the “Five Why’s” principle to each proposed user story, so that its purpose is clearly related to business outcomes
thinking “from the outside in”, in other words implement only those behaviors which contribute most directly to these business outcomes, so as to minimize waste
describe behaviors in a single notation which is directly accessible to domain experts, testers and developers, so as to improve communication
apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behavior, so that evolution remains cheap
將“五個為什麼”原則應用於每個提議的使用者故事，使其目的與業務成果明確相關
“由外而內”思考，換言之，只實施對這些業務成果有最直接貢獻的行為，以最大程度地減少浪費
用單一符號描述行為，領域專家、測試人員和開發人員可以直接訪問，以改善溝通
將這些技術一直應用到軟體的最低抽象級別，特別注意行為的分佈，從而用較低的成本實現功能的演進

Also Known As別稱

BDD is also referred to as Specification by Example.

BDD 也稱為用例子來描述的需求規格說明書。

Expected Benefits可能帶來的好處

Teams already using TDD or ATDD may want to consider BDD for several reasons:

已經使用 TDD 或 ATDD 的團隊可能出於以下幾個原因想要考慮 BDD：

BDD offers more precise guidance on organizing the conversation between developers, testers and domain experts
notations originating in the BDD approach, in particular the given-when-then canvas, are closer to everyday language and have a shallower learning curve compared to those of tools such as Fit/FitNesse
tools targeting a BDD approach generally afford the automatic generation of technical and end user documentation from BDD “specifications”
BDD 為組織開發人員、測試人員和領域專家之間的對話提供了更精確的指導
與 Fit/FitNesse 等工具相比，源自 BDD 方法的符號，尤其是場景-時間-動作畫布，更接近日常語言，並且學習曲線更淺
針對 BDD 方法的工具通常能夠根據 BDD“規範”自動生成技術和終端使用者文件

Common Pitfalls弊端

Although Dan North, who first formulated the BDD approach, claims that it was designed to address recurring issues in the teaching of TDD, it is clear that BDD requires familiarity with a greater range of concepts than TDD does, and it seems difficult to recommend a novice programmer should first learn BDD without prior exposure to TDD concepts

儘管首先制定 BDD 方法的 Dan North 聲稱它旨在解決 TDD 教學中反覆出現的問題，但很明顯，BDD 需要比 TDD 熟悉更多的概念，而且也不推薦一個新手程式設計師在沒有任何TDD概念基礎的情況下接觸 BDD。

The use of BDD requires no particular tools or programming languages, and is primarily a conceptual approach; to make it a purely technical practice or one that hinges on specific tooling would be to miss the point altogether

BDD 的使用不需要特定的工具或程式語言，主要是一種概念方法；這容易使其容易成為純粹的技術實踐，如果沒有好的工具，相關理念很難實施。

Origins緣起

2003: agiledox, the ancestor of BDD, is a tool generating technical documentation automatically from JUnit tests, written by Chris Stevenson
2004: Chris Matts and Dan North proposed the given-when-then canvas to expand the scope of BDD to business analysis and documents
2004: in order to test his hypotheses about de-emphasizing “test” terminology in favor of “behavior”, Dan North releases JBehave
2006: Dan North documents the approach in “Introducing BDD”
2006-2009: several new tools are released confirming the community’s investment in BDD, such as RSpec or more recently, Cucumber and GivWenZen

Signs of Use使用說明

A team using BDD should be able to provide a significant portion of “functional documentation” in the form of User Stories augmented with executable scenarios or examples.
Instead of referring to “tests”, a BDD practitioner will prefer the terms “scenario” and “specification”. As currently practiced, BDD aims to gather in a single place the specification of an outcome valuable to a user, generally using the role-feature matrix of (User Stories), as well as examples or scenarios expressed in the form given-when-then; these two notations being often considered the most readable.
In emphasizing the term “specification”, the intent of BDD is to provide a single answer to what many Agile teams view as separate activities: the creation of unit tests and “technical” code on one hand, the creation of functional tests and “features” on the other hand. This should lead to increased collaboration between developers, test specialists, and domain experts.
Rather than refer to “the unit tests of a class”, a practitioner or a team using BDD prefers to speak of “the specifications of the behavior of the class”. This reflects a greater focus on the documentary role of such specifications: their names are expected to be more expressive, and, when completed with their description in given-when-then format, to serve as technical documentation.
Rather than refer to “functional tests”, the preferred term will be “specifications of the product’s behavior”. The technical aspects of BDD are placed on an equal footing with techniques encouraging more effective conversation with customers, users and domain experts.
In addition to refactoring techniques already present in TDD, the design philosophy in BDD pays particular attention to appropriate distribution of responsibilities among classes, which leads its practitioners to emphasize “mocking”.
使用 BDD 的團隊應該能夠以使用者故事的形式提供大部分“功能文件”，並增加了可執行場景或示例。
BDD 從業者不會提及“測試”，而是更喜歡“場景”和“規範”這兩個術語。按照目前的做法，BDD 的目標是在一個地方收集對使用者有價值的結果的規範，通常使用（使用者故事）的角色特徵矩陣，以及以“場景-時間-行為”形式表達的示例或場景;這兩種符號通常被認為是最易讀的。
在強調術語“規範”時，BDD 的目的是為許多敏捷團隊視為獨立活動的內容提供單一答案：一方面建立單元測試和“技術”程式碼，一方面建立功能測試和“特性”。 “ 另一方面。這應該會導致開發人員、測試專家和領域專家之間加強協作。
與“類的單元測試”不同，使用 BDD 的從業者或團隊更喜歡談論“類的行為規範”。這反映了對此類規範的文件作用的更大關注：它們的名稱應該更具表現力，並且在以“何時給定”格式完成描述後，可用作技術文件。
首選術語不是“功能測試”，而是“產品行為規範”。BDD 的技術方面與鼓勵與客戶、使用者和領域專家進行更有效對話的技術處於同等地位。
除了 TDD 中已經存在的重構技術，BDD 中的設計理念特別關注類之間的適當職責分配，這導致其從業者強調“mocking”。

【翻譯稿】Behavior Driven Development (BDD)行為驅動開發