tdd

TDD — 测试驱动开发

铁律：先写失败的测试。始终如此。

Red-Green-Refactor 循环

RED   → Write a failing test for the NEXT behavior
GREEN → Write ONLY enough code to make it pass (no extras)
REFACTOR → Clean up code quality (tests must stay green after every change)
REPEAT

分步流程

1. RED 阶段

1. 找出接下来要实现的最小行为
2. 编写一个测试，用命名的 it() / test() / def test_ 描述该行为
3. 运行测试——它必须失败。如果通过了，说明测试有问题。
4. 确认失败消息是正确的失败（而不是语法错误）

// Example: RED — test fails because function doesn't exist yet
it('returns an empty array for an empty input', () => {
  const result = parseItems([]);
  expect(result).toEqual([]);  // FAILS: parseItems is not defined
});

2. GREEN 阶段

1. 编写让测试通过所需的最少代码
2. 不要添加额外逻辑、默认参数或「锦上添花」的功能
3. 运行所有测试——新测试必须通过，现有测试不得失败

// Example: GREEN — just enough to pass
function parseItems(input: string[]): string[] {
  return [];  // only enough for the current test
}

3. REFACTOR 阶段

1. 检查代码——能否在不改变行为的前提下让它更简洁？
2. 应用简化模式（参见 /ai-slop-cleaner 和 /coding-standards）
3. **每次修改后都运行测试。**如果测试失败，立即撤销修改。

TDD 闸门——何时停止

情况	操作
先写了代码再写测试	停下。删除生产代码。先写测试。
测试首次运行就通过（之前没有代码）	测试有问题——修改测试，让它先失败。
一个测试包含多个行为	停下。一个测试，一个行为。
为了加快进度而跳过重构	回头处理。在开发下一个功能前清理代码。

将测试命名为规范

测试是可执行的文档。将测试命名为完整的句子：

// BAD
it('test1', ...)
it('works with empty', ...)

// GOOD
it('returns empty array when input is empty', ...)
it('throws ValidationError when email is missing @', ...)
it('sends exactly one email when user registers', ...)

框架速查

框架	失败断言	运行单个测试
Vitest	expect(x).toBe(y)	npx vitest run -t "test name"
Jest	expect(x).toBe(y)	npx jest -t "test name"
pytest	assert x == y	pytest -k "test_name"
cargo test	assert_eq!(x, y)	cargo test test_name
go test	t.Errorf(...)	go test -run TestName

常见 TDD 陷阱

陷阱	修正方法
测试实现细节	测试行为（输出），而不是内部实现（私有方法）
一个测试覆盖 10 种行为	拆分为原子测试用例
什么都模拟（过度模拟）	仅在系统边界处模拟（数据库、HTTP、文件系统）
缺少三角验证	编写 2–3 个测试，促使正确实现逐步显现
未经三角验证的常量	return 42 能通过一个测试——添加第二个测试，迫使实现真正的逻辑

另请参阅

• @test-engineer — 测试策略、框架检测、覆盖率缺口分析
• /ultraqa — QA 循环：测试、验证、修复、重复
• /verify — 基于证据的完成情况验证