行為驅動開發（BDD）實戰：從 TDD 到「應該」思維的範式轉換

測試本身是好事，早期測試（如編碼時同步測試）更能顯著提升代碼質量。儘管認識到其重要性，業界仍未將「編碼前寫測試」確立為標準實踐。TDD 是極限編程（XP）的演進，而基於 TDD 的新飛躍——行為驅動開發（BDD）正悄然到來。本文邀請您一起體驗從 TDD 到 BDD 的直觀演進。

為什麼 TDD 不夠？

雖然測試優先對部分人有效，但並不普適。開發者常以「沒時間測試」「代碼太複雜難測試」為由拒絕 TDD。更深層的障礙在於概念本身：測試被視為反應式活動，「測試不存在的東西」聽起來矛盾。但若將焦點從「如何測試」轉移到「系統應該如何運行」——即規範——一切變得自然。

一段沒有「測試」只有「應該」的對話

Frank 問 Linda 什麼是棧。Linda 描述：先進後出，有 push()、pop()、peek()。Frank 追問細節：push 兩個對象後 pop 順序？空棧 pop 拋異常？push null 怎麼辦？整段對話全程未提「測試」，卻滿口「應該」。這正是 BDD 的核心：用「應該」驅動開發，比「測試」更自然、更符合人類思維。

JBehave：Java 平台的 BDD 框架

JBehave 源於 xUnit，強調「應該」而非「測試」。行為類無需繼承基類，方法名以 should 開頭（清單 1）。

public class StackBehavior {
    public void shouldThrowExceptionUponNullPush() throws Exception {}
    public void shouldThrowExceptionUponPopWithoutPush() throws Exception {}
    public void shouldPopPushedValue() throws Exception {}
    public void shouldPopSecondPushedValueFirst() throws Exception {}
    public void shouldLeaveValueOnStackAfterPeep() throws Exception {}
}

方法名即人類可讀句子，失敗報告極具可讀性（如 StackBehavior should throw exception upon null push）。

用行為驅動實現棧

第一步：定義拋異常行為

Linda 說 push null 應拋異常。先寫最簡 Stack（清單 2），再用 JBehave 的 Ensure 與 Block 建模期望（清單 3）。運行失敗（清單 4），隨後補全 push() 邏輯（清單 5），測試通過（清單 6）。

Fixture 支持

JBehave 提供 setUp()/tearDown()，每個行為方法前後執行（清單 7）。

後續行為：pop、peek、多元素順序、空棧 peek

依次實現 shouldThrowExceptionUponPopWithoutPush()（清單 8）、引入 ArrayList 持有數據（清單 9）、完善 pop()（清單 10-18）、驗證 shouldPopPushedValue()（清單 11-16）、驗證 LIFO 邏輯 shouldPopSecondPushedValueFirst()（清單 19）、shouldPopValuesInReverseOrder()（清單 20）、peek() 行為（清單 21-24）、空棧 peek() 返回 null（清單 25-27）。最終得到完整可工作的 Stack 類（清單 28）。

BDD 的本質：客戶與開發者的協作

對話中 Linda 實際是客戶/領域專家，Frank 是開發者。換成呼叫中心應用同理。客戶描述系統「應該」做什麼，開發者用 BDD 確保理解並實現。對許多開發者，從 TDD 轉向 BDD 是明智之舉：不再糾結測試，只關注需求與行為，確保軟件做它「應該」做的事。