「TDD 就是先寫測試再寫功能嘛，太慢了不實際。」——你只看到手法，沒看到哲學。
先講結論
TDD / BDD / SDD 本質上回答同一個問題：「你怎麼知道你寫的東西是對的？」 差別在於誰來定義「對」——開發者（TDD）、使用者場景（BDD）、規格合約（SDD）。三者不互斥，是不同層次。
TDD：用失敗的測試來思考
Red → Green → Refactor。
寫一個會失敗的測試（功能還沒實作）→ 用最簡單的方式讓它通過 → 在測試保護下重構。
TDD 真正在教你的不是「先寫測試」：
- 在寫功能前先想清楚邊界——輸入是什麼？null 怎麼辦？空陣列呢？
- 「最簡單的方式通過」不是偷懶，是逼你一次只解一個問題，避免過度設計
- 測試不是事後補的安全網，是設計工具——測試很難寫？通常代表你的 API 設計有問題
什麼時候特別有用？演算法、資料轉換、邊界條件多的場景。
什麼時候不太適合？UI 開發（行為難以 assert）、探索性開發（你還不知道要什麼）。
BDD：用場景來對齊期望
Given / When / Then。
Scenario: 密碼錯誤
Given 使用者已註冊
When 使用者用錯誤密碼登入
Then 應該看到「帳號或密碼錯誤」
And 不應該被導向首頁BDD 真正在教你的：
- 需求不是一句模糊的話，是一組可驗證的場景。PM 說「要有登入功能」，BDD 逼你問：「登入失敗顯示什麼？連續失敗三次呢？」
- 用人話寫測試，所有人都能參與 review——QA 補場景、PM 確認行為
- 場景就是活的文件，永遠跟 code 同步
什麼時候特別有用？功能型需求、跨角色溝通成本高的團隊。
SDD：用規格合約定義邊界
先定義介面，再分頭實作。
paths:
/users/{id}:
get:
parameters:
- name: id
in: path
required: true
schema:
type: integer
responses:
'200':
description: 成功
'404':
description: 使用者不存在SDD 真正在教你的：
- 合約是團隊協作的基礎——前後端可以同時開工
- 規格即文件、即測試、即 mock——一份 OpenAPI 自動生成 mock server、client SDK、API 文件
- 強迫你在寫第一行 code 前就想清楚 API 的形狀
什麼時候特別有用？前後端分離、微服務（gRPC / Protobuf）、公開 API。
三者怎麼搭配
一個成熟專案可能同時用：
SDD — 定義 API 合約（團隊對齊）
↓
BDD — 定義功能場景（需求驗證）
↓
TDD — 定義單元行為（實作品質）
就像蓋房子：SDD 是藍圖、BDD 是「住進去什麼體驗」、TDD 是「每根柱子承重夠不夠」。
你該怎麼選？不要問「用哪個」，問「痛在哪」
| 你的痛點 | 適合的方向 |
|---|---|
| 邊界條件沒想到就出 bug | TDD |
| PM 驗收說「這不是我要的」 | BDD |
| 前後端一直在等對方 | SDD |
| 重構怕改壞東西 | TDD |
| 文件永遠跟 code 不同步 | SDD |
延伸閱讀
- 測試策略 — 測試金字塔與各層次實務
- API 設計與認證機制 — SDD 的實際應用
- 系統分析與設計 — 從需求到規格的完整流程
AI 可以幫你生成測試、場景、規格。但你知道該生成什麼嗎？——這才是你要掌握的。