03 · TDD 工作流

TDD（测试驱动开发）的本质是：先定义「什么叫做好」，再让人（或 AI）实现它。

和 Claude Code 配合时，TDD 效率极高——你写测试定义需求，Claude 写实现通过测试。

TDD 基本节奏

你：写测试（定义需求）
  ↓
Claude：写实现（通过测试）
  ↓
你：审查实现，如果不满意修改测试要求
  ↓
Claude：调整实现

从需求描述到测试

你不需要懂实现细节，只需要描述「什么叫做正确」：

我要写一个购物车模块（cartStore.ts，用 Zustand）。
先帮我写测试文件 /src/stores/__tests__/cartStore.test.ts，
不要写实现。

测试要覆盖：
- 初始状态：items 为空数组，total 为 0
- addItem：加入新商品，数量 +1；加入已有商品，数量叠加
- removeItem：移除商品
- updateQuantity：更新数量，数量为 0 时自动移除
- clearCart：清空购物车
- total 计算：price × quantity 的总和，保留两位小数

Claude 生成测试，你确认测试逻辑是否正确，然后：

测试逻辑没问题。现在写 cartStore.ts 的实现，让所有测试通过。

用测试描述 API 契约

后端 API 还没写，前端先写调用层的测试：

为 /src/api/auth.ts 写测试，定义 API 契约：

login(email, password)：
- 成功时返回 { token: string, user: User }，调用 POST /api/auth/login
- 失败时抛出包含 message 的 Error

logout()：
- 调用 DELETE /api/auth/session，清除本地 token

所有 HTTP 请求 mock 掉（用 vitest 的 vi.mock）。

有了测试，Claude 实现 auth.ts 时就有了明确的被测接口规范。

TDD 修 Bug

Bug 修复前先写一个能复现 bug 的测试：

useCart 的 updateQuantity 有 bug：当数量更新为 0 时，
商品没有被移除，变成了 0 个商品还在列表里。

先写一个能复现这个 bug 的测试（测试应该失败），
然后修复 bug 让测试通过。

这样修完 bug 就自动有了回归测试，保证以后不会再出现。

什么时候不适合 TDD

• 原型验证阶段，需求还在变
• UI 样式类的工作（视觉很难用测试定义）
• 第三方服务集成（mock 成本高）

TDD 最有价值的场景是：业务逻辑、状态管理、工具函数。