BDD

BDD(Behaviour-Driven Development)

定義

以行為描述驅動開發的方法論。用 Gherkin 語法(Given/When/Then)寫出驗收條件,作為開發和測試的 single source of truth。

起源

BDD 最初是為了讓 TDD 更容易教學而設計的,從 TDD 的紅燈/綠燈/重構循環延伸,加入驗收測試和通用語言層。

家族體系

方法 全稱 偏向
BDD Behaviour-Driven Development 整體框架
ATDD Acceptance Test-Driven Development 偏驗收開發端
SBE Specification by Example 偏業務端

三者屬同一家族,視角不同但目標一致。

為什麼需要 BDD(來源:BDD in Action

BDD 解決兩個不同層次的品質問題:

層次 意思 傳統失敗模式
Building the right software 做對的東西 通過測試但不符合真正需求
Building the software right 把東西做對 符合需求但品質不足

傳統流程 vs BDD

傳統: 業務人員 → 業務分析師 → 開發人員 → QA → 技術文件(線性傳遞,每步都有資訊流失)

BDD: 業務代表、開發者、測試人員三方協作(Three Amigos),共同產出具體場景與驗收標準,場景即自動化測試、即活文件(Living Documentation)。

原則(來源:Ch.2)

  1. 專注業務價值 — 對齊 User Story,只做有價值的功能
  2. 擁抱不確定性 — 需求在過程中才會清晰,持續從利害關係人取得回饋
  3. 具體範例 — 用 Given/When/Then 寫出具體場景,含 corner case 和澄清性假設

核心價值

  1. 處理不確定性 — 花時間釐清規格比直接寫 code 更重要
  2. 消除翻譯層 — 用 ubiquitous language 寫場景,三方都能讀懂
  3. 活文件 — Gherkin 場景同時是規格、測試、文件,永遠與程式碼同步
  4. 進度可視化 — 場景通過 = 功能完成

Gherkin 語法與可執行規格

關鍵字 用途
Given 前提條件、環境準備
When 被測試的動作(API 呼叫、方法觸發)
Then 驗證回傳值或系統後狀態
關鍵區分

BDD 寫的不是「自動化測試」,而是「可執行規格」(Executable Specification)。Cucumber 作為橋接工具,將 Gherkin 的每個 step 連結到 Step Definition 程式碼。

優點

  1. 減少浪費 — 專注業務價值,不做不符目標的功能
  2. 降低成本 — 可執行規格持續驗收,減少 bug 成本
  3. 更安全的變更 — 自動化回歸測試,支持持續交付
  4. 更快的發佈 — 取代 QA 長時間手動測試

挑戰

  1. 高度業務參與 — 需持續與利害關係人對話
  2. 無法事先定義所有需求 — 敏捷環境效果好,但需要需求分析能力
  3. 測試維護成本 — 測試寫得不好反而增加負擔,需要抽象層設計

BDD + AI 的研究空間

User Story
    ↓ [LLM 已有多篇研究]
Gherkin Scenario
    ↓ [幾乎沒人做,這是研究 gap]
Step Definitions + Implementation Code
    ↓ [已有工具但不完整]
Passing Tests

研究現況(截至 2026-03)

Prompt 策略矛盾

各論文的 few-shot vs zero-shot 結果相互矛盾。詳見 Prompt 策略

可用 Dataset

Dataset 規模 狀態
E2EDev Benchmark 703 scenarios (46 projects) 已下載,已提取 pairs
SelfBehave 1,097 generated pairs 已下載
Benchmark-paired 308 features (102 with step defs) 已配對
Ground Truth Baseline

99.9% syntax / 94.9% step match / 99.8% impl rate

相關概念