aile-tdd（艾乐 tdd）

測試驅動開發 (TDD)

来源原 Skill

• 来源：superpowers TDD 能力（已迁移为 aile-only）
• 策略：保留 RED → GREEN → REFACTOR 闭环，并与团队阶段流程对齐。

概述

先寫測試。看著它失敗。編寫最少的程式碼即可通過。

核心原則： 如果你沒有看到測試失敗，你就不知道它是否測試了正確的東西。

違反規則的字面意思就是違反規則的精神。

何時使用

總是：

• 新功能
• 錯誤修復
• 重構
• 行為改變

例外（詢問你的人類夥伴）：

• 一次性原型
• 生成的代碼
• 配置文件

想「這次跳過 TDD」嗎？停止吧。這就是合理化。

鐵律

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

測試前先寫代碼？刪除它。重新開始。

沒有例外：

• 不要將其保留為“參考”
• 編寫測試時不要“適應”它
• 別看它
• 刪除就是刪除

實施新的測試。時期。

紅綠重構

digraph tdd_cycle {
    rankdir=LR;
    red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"];
    verify_red [label="Verify fails\ncorrectly", shape=diamond];
    green [label="GREEN\nMinimal code", shape=box, style=filled, fillcolor="#ccffcc"];
    verify_green [label="Verify passes\nAll green", shape=diamond];
    refactor [label="REFACTOR\nClean up", shape=box, style=filled, fillcolor="#ccccff"];
    next [label="Next", shape=ellipse];

    red -> verify_red;
    verify_red -> green [label="yes"];
    verify_red -> red [label="wrong\nfailure"];
    green -> verify_green;
    verify_green -> refactor [label="yes"];
    verify_green -> green [label="no"];
    refactor -> verify_green [label="stay\ngreen"];
    verify_green -> next;
    next -> red;
}

紅色 - 寫入失敗測試

編寫一個最小的測試來顯示應該發生什麼。

<好>

test('retries failed operations 3 times', async () => {
  let attempts = 0;
  const operation = () => {
    attempts++;
    if (attempts < 3) throw new Error('fail');
    return 'success';
  };

  const result = await retryOperation(operation);

  expect(result).toBe('success');
  expect(attempts).toBe(3);
});

清晰的名字，測試真實的行為，一件事 </好>

<壞>

test('retry works', async () => {
  const mock = jest.fn()
    .mockRejectedValueOnce(new Error())
    .mockRejectedValueOnce(new Error())
    .mockResolvedValueOnce('success');
  await retryOperation(mock);
  expect(mock).toHaveBeenCalledTimes(3);
});

模糊的名稱，測試模擬而不是代碼 </壞>

要求：

• 一種行為
• 清晰的名字
• 真實程式碼（除非不可避免，否則不進行模擬）

驗證紅色 - 觀察失敗

強制的。切勿跳過。

npm test path/to/test.test.ts

確認：

• 測試失敗（不是錯誤）
• 預計會出現失敗訊息
• 由於功能缺失（不是拼寫錯誤）而失敗

測試通過？ 您正在測試現有行為。修復測試。

測試錯誤？ 修復錯誤，重新運行，直到正確失敗。

綠色 - 最少代碼

編寫最簡單的程式碼來通過測試。

<好>

async function retryOperation<T>(fn: () => Promise<T>): Promise<T> {
  for (let i = 0; i < 3; i++) {
    try {
      return await fn();
    } catch (e) {
      if (i === 2) throw e;
    }
  }
  throw new Error('unreachable');
}

只要夠通過即可 </好>

<壞>

async function retryOperation<T>(
  fn: () => Promise<T>,
  options?: {
    maxRetries?: number;
    backoff?: 'linear' | 'exponential';
    onRetry?: (attempt: number) => void;
  }
): Promise<T> {
  // YAGNI
}

過度設計 </壞>

不要添加功能、重構其他程式碼或在測試之外進行「改進」。

驗證綠色 - 觀察它通過

強制的。

npm test path/to/test.test.ts

確認：

• 測試通過
• 其他測試仍然通過
• 輸出原始（沒有錯誤、警告）

測試失敗？ 修復代碼，而不是測試。

其他測試失敗？ 立即修復。

重構 - 清理

僅綠色之後：

• 刪除重複項
• 改進名字
• 提取助手

保持測試綠色。不要添加行為。

重複

下一個功能的下一個失敗測試。

良好的測試

為什麼訂單很重要

“我會在之後編寫測試來驗證它是否有效”

程式碼通過後編寫的測試立即通過。立即通過並不能證明什麼：

• 可能測試錯誤的東西
• 可能測試實施，而不是行為
• 可能會錯過您忘記的邊緣情況
• 你從未遇到過它捕獲 bug

測試優先迫使您看到測試失敗，證明它確實測試了某些東西。

「我已經手動測試了所有邊緣情況」

手動測試是臨時的。您認為您測試了所有內容，但：

• 沒有記錄您測試的內容
• 代碼更改後無法重新運行
• 在壓力下容易忘記案件
• “我嘗試了一下就成功了”≠全面

自動化測試是系統化的。他們每次都以同樣的方式奔跑。

「消除X小時的工作就是浪費」

沉沒成本謬誤。時間已經過去了。您現在的選擇：

• 使用TDD刪除並重寫（多花幾個小時，高可信度）
• 保留它並在之後添加測試（30 分鐘，低置信度，可能存在錯誤）

“浪費”是保留你不信任的代碼。沒有真正測試的工作代碼是技術債。

「TDD 是教條主義的，務實意味著適應」

TDD 很務實：

• 在提交之前發現錯誤（比之後調試更快）
• 防止回歸（測試立即捕獲中斷）
• 文檔行為（測試顯示如何使用程式碼）
• 啟用重構（自由更改，測試捕獲中斷）

“實用”快捷方式=生產中的調試=速度較慢。

「達到相同目標後進行測試 - 這是精神而不是儀式」

不。回答後測試“這有什麼作用？”測試優先回答“這應該做什麼？”

之後的測試因您的實現而存在偏差。您測試您構建的內容，而不是測試所需的內容。您驗證記住的邊緣情況，而不是發現的情況。

測試優先強制在實施之前發現邊緣情況。測試 - 驗證您記住了所有內容（您沒有記住）。

≠ TDD 經過 30 分鐘的測試。你得到了保險，失去了證明測試的工作。

常見的合理化理由

危險信號 - 停止並重新開始

• 測試前的代碼
• 實施後測試
• 測試立即通過
• 無法解釋測試失敗的原因
• “稍後”添加測試
• 合理化“就這一次”
• “我已經手動測試過了”
• “達到相同目的後進行測試”
• “這是關於精神而不是儀式”
• “保留作為參考”或“改編現有代碼”
• “已經花了X個小時了，刪掉太浪費了”
• “TDD很教條，我很務實”
• “這是不同的，因為……”

所有這些意味著：刪除計劃碼。從TDD開始。

示例：錯誤修復

錯誤： 接受空電子郵件

紅色的

test('rejects empty email', async () => {
  const result = await submitForm({ email: '' });
  expect(result.error).toBe('Email required');
});

驗證紅色

$ npm test
FAIL: expected 'Email required', got undefined

綠色的

function submitForm(data: FormData) {
  if (!data.email?.trim()) {
    return { error: 'Email required' };
  }
  // ...
}

驗證綠色

$ npm test
PASS

重構 如果需要，提取多個欄位的驗證。

驗證清單

在標記工作完成之前：

• 每個新函數/方法都有一個測試
• 在實施之前觀察每個測試的失敗
• 每個測驗都因預期原因而失敗（功能缺失，而非拼字錯誤）
• 編寫最少的代碼來通過每個測試
• 所有測試均通過
• 輸出原始（沒有錯誤、警告）
• 測試使用真實程式碼（僅在不可避免時才進行模擬）
• 涵蓋的邊緣情況和錯誤

無法完成所有中斷嗎？你跳過了 TDD。重新開始。

卡住時

偵錯集成

發現錯誤了嗎？寫一個失敗的測試來重置它。遵循TDD週期。測試證明可以修復並阻止回歸。

未經測試切勿修復錯誤。

測試反模式

在新增模擬或測試實用程式時，請閱讀@testing-anti-patterns.md分區常見陷阱：

• 測試模擬行為而不是真實行為
• 將僅測試方法添加到生產類中
• 在不瞭解依賴關係的情況下進行模擬

最終規則

Production code → test exists and failed first
Otherwise → not TDD

未經您的人類伴侶許可，也不例外。