TDD 原来要这么做！GitHub 26万星开发方法论开源了

写代码前先写测试？听起来反直觉，但 TDD 真的是最快、最稳的代码思路。

我之前也觉得 TDD 麻烦——”先把功能写完再测不就行了？” 结果呢？代码越堆越乱，测起来满屏 mock，边界 case 根本不敢动。这种”先写代码后补测试”的思路，本质上是在给自己挖坟。

直到我把这个 Skill 喂给了我的 Claude Code。

先看一个扎心的对比

同一个功能，两种写法：

错误示范：

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

问题在哪？测试的是 mock，不是行为。一旦实现变了这测试就废。

正确姿势：

test('重试失败的操作 3 次', 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);
});

名字说人话，测试真实行为，不依赖任何 mock。

TDD 的铁律：红-绿-重构

这个 Skill 把 TDD 拆成了严格的三步循环，每一步都有强制验证点：

RED — 先写一个会失败的测试
写测试前不能写实现代码。如果已经写了？删掉，从头来。这听起来极端，但只有看着测试fail，才知道它真的在测对的东西。

GREEN — 只写刚好让测试通过的最少代码
不要在这里做优化、加功能、或者”顺手改一下别的”。最小化实现，通过就行。

REFACTOR — 绿灯后清理
这时候才允许重构——去重、改善命名、提取工具函数。测试全程保持绿色。

每一步都有强制验证命令：npm test path/to/test.test.ts，必须看到失败才能停。

为什么这个 Skill 值得装

26万星的 obra/superpowers 是 GitHub 上最火的 AI Coding Agent 框架之一。这个 TDD Skill 不是空谈方法论，它直接给 Claude agent 用的workflow prompt——能让 AI 也遵循 TDD 循环，而不是上来就给你生成一坨代码。

适用场景：
– 新功能开发：AI 帮你先想清楚边界，再写实现
– Bug 修复：测试先写，重现问题，再修
– 重构：测试先行，保证改完不破坏行为

说人话版使用方式

在 Claude Code 里加载这个 Skill：

/proj # 加载 superpower skill 后直接开工

它会自动在写任何实现前，要求你先描述测试场景。强制你回答：这个功能要测什么？边界在哪？失败了应该是什么样子？

真正的 TDD 就是这样：不是先写代码后测，而是先用测试把需求锁定。

GitHub：https://github.com/obra/superpowers

GitHub: https://github.com/obra/superpowers