測試驅動開發 (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確認：
- 測試通過
- 其他測試仍然通過
- 輸出原始（沒有錯誤、警告）
測試失敗？ 修復代碼，而不是測試。
其他測試失敗？ 立即修復。
重構 - 清理
僅綠色之後：
- 刪除重複項
- 改進名字
- 提取助手
保持測試綠色。不要添加行為。
重複
下一個功能的下一個失敗測試。
良好的測試
| 品質 | 好 | 不好 |
|---|---|---|
| 最小 | 一件事。名字中的“和”？分開它。 | test('validates email and domain and whitespace') |
| 清除 | 名稱描述行為 | test('test1') |
| 表明意圖 | 所需需要的API | 模糊了程序代碼執行 |
為什麼訂單很重要
“我會在之後編寫測試來驗證它是否有效”
程式碼通過後編寫的測試立即通過。立即通過並不能證明什麼：
- 可能測試錯誤的東西
- 可能測試實施，而不是行為
- 可能會錯過您忘記的邊緣情況
- 你從未遇到過它捕獲 bug
測試優先迫使您看到測試失敗，證明它確實測試了某些東西。
「我已經手動測試了所有邊緣情況」
手動測試是臨時的。您認為您測試了所有內容，但：
- 沒有記錄您測試的內容
- 代碼更改後無法重新運行
- 在壓力下容易忘記案件
- “我嘗試了一下就成功了”≠全面
自動化測試是系統化的。他們每次都以同樣的方式奔跑。
「消除X小時的工作就是浪費」
沉沒成本謬誤。時間已經過去了。您現在的選擇：
- 使用TDD刪除並重寫（多花幾個小時，高可信度）
- 保留它並在之後添加測試（30 分鐘，低置信度，可能存在錯誤）
“浪費”是保留你不信任的代碼。沒有真正測試的工作代碼是技術債。
「TDD 是教條主義的，務實意味著適應」
TDD 很務實：
- 在提交之前發現錯誤（比之後調試更快）
- 防止回歸（測試立即捕獲中斷）
- 文檔行為（測試顯示如何使用程式碼）
- 啟用重構（自由更改，測試捕獲中斷）
“實用”快捷方式=生產中的調試=速度較慢。
「達到相同目標後進行測試 - 這是精神而不是儀式」
不。回答後測試“這有什麼作用？”測試優先回答“這應該做什麼？”
之後的測試因您的實現而存在偏差。您測試您構建的內容，而不是測試所需的內容。您驗證記住的邊緣情況，而不是發現的情況。
測試優先強制在實施之前發現邊緣情況。測試 - 驗證您記住了所有內容（您沒有記住）。
≠ TDD 經過 30 分鐘的測試。你得到了保險，失去了證明測試的工作。
常見的合理化理由
| 對不起 | 現實 |
|---|---|
| “太簡單了，無法測試” | 簡單的代碼中斷。測試需要 30 秒。 |
| “之後我會測試” | 測試立即通過並不能證明什麼。 |
| “達到相同目標後再進行測試” | Tests-after =“這是做什麼的？”測試優先=“這應該做什麼？” |
| “已經手動測試” | 臨時性≠系統性。沒有記錄，無法重新運行。 |
| “刪除X小時是浪費” | 沉沒成本謬誤。保留默認驗證的代碼是技術債。 |
| 「留作參考，先寫測驗」 | 你會適應它。後面就是測試了刪除就是刪除的意思。 |
| “需要先探索” | 美好的。放棄探索，從TDD開始。 |
| “努力測試=設計不清楚” | 聽聽測試。難以測試=難以使用。 |
| “TDD 會讓我放慢速度” | TDD 比調試更快。務實=測試第一。 |
| “手動測試速度更快” | 手冊不能證明邊緣情況。您將重新測試每個變更。 |
| “現有代碼沒有經過測試” | 你正在改進它。為現有代碼添加測試。 |
危險信號 - 停止並重新開始
- 測試前的代碼
- 實施後測試
- 測試立即通過
- 無法解釋測試失敗的原因
- “稍後”添加測試
- 合理化“就這一次”
- “我已經手動測試過了”
- “達到相同目的後進行測試”
- “這是關於精神而不是儀式”
- “保留作為參考”或“改編現有代碼”
- “已經花了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。重新開始。
卡住時
| 問題 | 解決方案 |
|---|---|
| 不知道如何測試 | 編寫想要的API。先寫斷言。詢問你的人類夥伴。 |
| 測試太複雜 | 設計太複雜了。簡化界面。 |
| 必須嘲笑一切 | 代碼耦合性太強。使用依賴注入。 |
| 測試設定巨大 | 提取助手。還是很複雜？簡化設計。 |
偵錯集成
發現錯誤了嗎？寫一個失敗的測試來重置它。遵循TDD週期。測試證明可以修復並阻止回歸。
未經測試切勿修復錯誤。
測試反模式
在新增模擬或測試實用程式時，請閱讀@testing-anti-patterns.md分區常見陷阱：
- 測試模擬行為而不是真實行為
- 將僅測試方法添加到生產類中
- 在不瞭解依賴關係的情況下進行模擬
最終規則
Production code → test exists and failed first
Otherwise → not TDD未經您的人類伴侶許可，也不例外。