【superpowers基本Skill】test-driven-development 技能

在实现任何功能或bug修复时使用，在编写实现代码之前

技能概述

test-driven-development 技能：先写测试。看它失败。编写最小代码通过。核心原则:如果你没有看测试失败，你就不知道它是否测试了正确的东西。违反规则的字面意思就是违反规则的精神。

主要功能

• RED – 编写失败测试: 编写一个显示应该发生什么的最小测试
• 验证RED: 观看它失败(强制)
• GREEN – 最小代码: 编写最简单的代码通过测试
• 验证GREEN: 观看它通过(强制)
• REFACTOR – 清理: 删除重复，改进名称，提取助手

触发条件

在以下情况下应该调用此技能:

总是:

• 新功能
• Bug修复
• 重构
• 行为更改

例外(询问你的合作伙伴):

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

铁律

没有失败测试就没有生产代码

在测试之前写代码?删除它。重新开始。

无例外:

• 不保留它作为"参考"
• 不"适应"它而写测试
• 不看它
• 删除意味着删除

从测试开始实现。周期。

红-绿-重构循环

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);
});

模糊名称，测试模拟而不是代码

要求:

• 一个行为
• 清晰名称
• 真实代码(除非不可避免，否则没有模拟)

验证RED – 观看它失败

强制。从不跳过。

npm test path/to/test.test.ts

确认:

• 测试失败(不是错误)
• 失败消息是预期的
• 失败因为功能缺失(不是拼写错误)

测试通过? 你在测试现有行为。修复测试。

测试错误? 修复错误，重新运行直到它正确失败。

GREEN – 最小代码

编写最简单的代码通过测试。

好:

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
}

过度工程

不要添加功能，重构其他代码，或"改进"超出测试。

验证GREEN – 观看它通过

强制。

npm test path/to/test.test.ts

确认:

• 测试通过
• 其他测试仍然通过
• 输出干净(无错误，警告)

测试失败? 修复代码，不是测试。

其他测试失败? 现在修复。

REFACTOR – 清理

仅在绿色之后:

• 删除重复
• 改进名称
• 提取助手

保持测试绿色。不要添加行为。

重复

下一个功能的下一个失败测试。

好测试

为什么顺序很重要

"我会在之后写测试以验证它工作"

代码之后写的测试立即通过。立即通过证明什么都没有:

• 可能测试错误的东西
• 可能测试实现，不是行为
• 可能错过你忘记的边缘情况
• 你从未看到它捕获bug

测试先强制你看测试失败，证明它实际测试某些东西。

"我已经手动测试了所有边缘情况"

手动测试是临时的。你认为你测试了一切但:

• 没有你测试的记录
• 代码更改时无法重新运行
• 压力下容易忘记情况
• "它工作时我试过"≠全面

自动化测试是系统性的。它们每次以相同方式运行。

"删除X小时工作是浪费"

沉没成本谬误。时间已经消失。你现在选择:

• 删除并用TDD重写(X更多小时，高信心)
• 保持并在之后添加测试(30分钟，低信心，可能bug)

"浪费"是保持你无法信任的代码。没有真实测试的工作代码是技术债务。

"TDD是教条的，务实意味着适应"

TDD是务实的:

• 在提交前发现bug(比之后调试更快)
• 防止回归(测试立即捕获中断)
• 文档行为(测试显示如何使用代码)
• 启用重构(自由更改，测试捕获中断)

"务实"捷径 = 在生产中调试 = 更慢。

"测试后达到相同目标 – 是精神不是仪式"

不。测试后回答"这做什么?"测试先回答"这应该做什么?"

测试后被你的实现偏见。你测试你构建的，不是要求的。你验证记住的边缘情况，不是发现的。

测试先强制边缘情况发现在实现之前。测试后验证你记住了一切(你没有)。

测试后30分钟≠TDD。你获得覆盖，失去证明测试工作。

常见合理化

红旗警告 – 停止并重新开始

• 代码在测试之前
• 实现后测试
• 测试立即通过
• 不能解释为什么测试失败
• "稍后"添加测试
• 合理化"只是这一次"
• "我已经手动测试了"
• "测试后达到相同目的"
• "是精神不是仪式"
• "保持为参考"或"适应现有代码"
• "已经花了X小时，删除是浪费"
• "TDD是教条的，我是务实的"
• "这是不同的因为…"

所有这些意味着:删除代码。从TDD重新开始。

示例: Bug修复

Bug: 空电子邮件被接受

RED

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

验证RED

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

GREEN

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

验证GREEN

$ npm test PASS

REFACTOR

如果需要，提取验证以用于多个字段。

验证检查清单

在标记工作完成之前:

• [ ] 每个新函数/方法有测试
• [ ] 在实现之前观看每个测试失败
• [ ] 每个测试因预期原因失败(功能缺失，不是拼写错误)
• [ ] 编写最小代码通过每个测试
• [ ] 所有测试通过
• [ ] 输出干净(无错误，警告)
• [ ] 测试使用真实代码(仅不可避免时模拟)
• [ ] 边缘情况和错误覆盖

不能检查所有框?你跳过了TDD。重新开始。

卡住时

调试集成

发现bug?编写重现它的失败测试。遵循TDD循环。测试证明修复并防止回归。

从不没有测试修复bug。

最终规则

生产代码 → 测试存在并先失败
否则 → 不是TDD

没有你的合作伙伴许可无例外。

下载地址: https://github.com/obra/superpowers/tree/main/skills/test-driven-development