Vincent5588 Wiki

Vibe Coding TDD 三條 e2e 測試

閱讀時間約 5 分鐘

Vibe Coding TDD 三條 e2e 測試

Vibe Coding 的簡化版 TDD 規範。Erik Schluntz 實戰建議：「明確告訴 Claude 只寫三條 end-to-end 測試：一條 happy path、一條錯誤情境、另一條錯誤情境」。

三條測試結構

#類型目的
1Happy path正常使用情境跑通
2錯誤情境 A譬如未授權 / 輸入無效
3錯誤情境 B另一種 error path（譬如資源不存在 / 衝突）

為什麼只 3 條（不是 30 條）

避免：

  • ❌ 寫了一堆綁太死實作細節的測試
  • ❌ 測試多到 reviewer 不想看
  • ❌ 每次重構都要改一堆測試
  • ❌ 過度測試造成 過度約束反效應

3 條 e2e 測試剛好夠驗證「主要使用情境 + error handling 不漏」，又不會綁死實作。

撰寫順序很重要

先給測試規範，再讓 AI 寫實作。

具體流程：

請先列出你要寫的 3 條 e2e 測試的「描述」（不要寫實作）：
  1. happy path
  2. 錯誤情境 A
  3. 錯誤情境 B
我確認後，再請你寫測試 + 實作。

兩個分階段：

  1. AI 列描述 → 人類審閱 → 確認 OK
  2. AI 寫測試 + 實作

避免「AI 寫完才發現測試 cover 錯地方」。

Erik 原話：只讀測試的工作流

很多時候我 vibe coding 後，只讀測試。如果測試合理、且測試通過，我就對程式碼有信心。

這就是 可驗證性設計三支柱 的具體落實——「reviewer 不讀實作能判斷正確嗎？」答案：讀 3 條 e2e 測試就夠。

規範底線

條件要求
每個 leaf node feature至少 3 條 e2e 測試
測試層級「使用者能理解的層級」，不是內部實作細節
Core code 改動測試由人類主導撰寫 / 審閱（不能丟給 AI 寫測試自驗）

測試「使用者能理解的層級」是什麼意思

❌ 不該（綁實作細節）：

it("should call ActivityReportService.getActivityByDateRange with correct args", () => {
  expect(mockService).toHaveBeenCalledWith({ from, to, limit: 100 });
});

✅ 該（使用者可理解）：

it("returns activity records for a given date range", async () => {
  const res = await api.get("/admin/reports/activity?from=2026-01-01&to=2026-01-31");
  expect(res.status).toBe(200);
  expect(res.body.records).toBeInstanceOf(Array);
});

差別：第一種綁了「method name + 內部 args」，refactor 一改就壞；第二種只測 contract（API endpoint 行為），可長期維持。

對照其他 TDD 風格

TDD 風格測試數適用
Vibe TDD（本規範）3 條 e2eAI 大量產出、leaf node、要快速驗收
傳統 TDD數十條 unit + integrationCore code、長期維護模組
Property-based testing多條 generativeAlgorithm-heavy、邊界條件多
Snapshot testing多條 snapshotUI 元件、序列化格式

不衝突——Vibe TDD 是「最低底線」，core code 場景仍可疊加更多測試風格。

落地工具

  • Vitest / Jest / pytest — 標準 e2e 框架
  • Playwright / Cypress — 真 e2e（含 UI）
  • AI 產測試的 prompt template（可包成 Skills 九種類型）

跟其他 Vibe Coding 元素的關係

關聯說明
建立可驗證檢查點 法則法則四的具體落地
可驗證性設計三支柱「測試覆蓋」支柱的最低標準
Prompt 必備六元素六元素的「驗證標準」要列這 3 條
AI 編程 PR 模板PR 內必含這 3 條 e2e 結果
聚焦 Leaf Nodes 法則Leaf node 才用 3 條足；core 要更多

違反時的常見症狀

  • ❌ 「30 條 unit test 但沒 e2e」→ 沒測 contract，refactor 易壞
  • ❌ 「只 happy path 沒 error path」→ 漏邊界
  • ❌ 「測試綁實作（mock 一堆內部 method）」→ refactor 一動就紅
  • ❌ 「Core code 也只 3 條 e2e」→ 不夠，core 要疊加 unit 測

相關

關係圖譜

反向連結