TDD 红灯测试

---

name: tdd-workflows-tdd-red description: "为 TDD 红色阶段生成失败测试，以定义预期行为和边界情况。" risk: unknown source: community date_added: "2026-02-27"

编写遵循 TDD 红色阶段原则的全面失败测试。

[扩展思考：使用 test-automator 代理生成正确定义预期行为的失败测试。]

适用场景

• 为新行为启动 TDD 红色阶段时
• 需要捕获预期行为的失败测试时
• 在实现之前需要边界情况覆盖时

不适用场景

• 处于绿色或重构阶段时
• 只需要性能基准测试时
• 测试必须针对生产系统运行时

指导说明

1. 识别行为、约束和边界情况。
2. 生成定义预期结果的失败测试。
3. 确保失败是由于缺少行为，而非设置错误。
4. 记录如何运行测试和验证失败。

安全性

• 保持测试数据隔离，避免生产环境。
• 在红色阶段避免不稳定的外部依赖。

角色

使用 Task 工具和 subagent_type="unit-testing::test-automator" 生成失败测试。

提示模板

"为以下内容生成全面的失败测试：$ARGUMENTS

核心要求

1. 测试结构

   • 框架适配的设置（Jest/pytest/JUnit/Go/RSpec）
   • Arrange-Act-Assert 模式
   • should_X_when_Y 命名约定
   • 无相互依赖的隔离 fixture

2. 行为覆盖

   • 正常路径场景
   • 边界情况（空值、null、边界值）
   • 错误处理和异常
   • 并发访问（如适用）

3. 失败验证

   • 测试运行时必须失败
   • 因正确原因失败（非语法/导入错误）
   • 有意义的诊断错误消息
   • 无级联失败

4. 测试类别

   • 单元：隔离的组件行为
   • 集成：组件交互
   • 契约：API/接口契约
   • 属性：数学不变量

框架模式

JavaScript/TypeScript (Jest/Vitest)

• 使用 vi.fn() 或 jest.fn() 模拟依赖
• 对 React 组件使用 @testing-library
• 使用 fast-check 进行属性测试

Python (pytest)

• 使用适当作用域的 Fixture
• 使用 Parametrize 进行多测试用例
• 使用 Hypothesis 进行基于属性的测试

Go

• 带子测试的表驱动测试
• t.Parallel() 用于并行执行
• 使用 testify/assert 获得更清晰的断言

Ruby (RSpec)

• let 用于延迟加载，let! 用于立即加载
• 使用 Context 区分不同场景
• 使用 Shared examples 处理通用行为

质量检查清单

• 可读的测试名称记录意图
• 每个测试一个行为
• 无实现泄漏
• 有意义的测试数据（非 'foo'/'bar'）
• 测试作为活文档

要避免的反模式

• 测试立即通过
• 测试实现而非行为
• 复杂的设置代码
• 每个测试多个职责
• 与具体细节绑定的脆弱测试

边界情况类别

• Null/空值：undefined、null、空字符串/数组/对象
• 边界：最小/最大值、单元素、容量限制
• 特殊情况：Unicode、空白字符、特殊字符
• 状态：无效转换、并发修改
• 错误：网络故障、超时、权限

输出要求

• 包含导入的完整测试文件
• 测试目的文档
• 运行和验证失败的命令
• 指标：测试数量、覆盖区域
• 绿色阶段的后续步骤"

验证

生成后：

1. 运行测试 - 确认它们失败
2. 验证有帮助的失败消息
3. 检查测试独立性
4. 确保全面覆盖

示例（最小化）

// auth.service.test.ts
describe('AuthService', () => {
  let authService: AuthService;
  let mockUserRepo: jest.Mocked<UserRepository>;

  beforeEach(() => {
    mockUserRepo = { findByEmail: jest.fn() } as any;
    authService = new AuthService(mockUserRepo);
  });

  it('should_return_token_when_valid_credentials', async () => {
    const user = { id: '1', email: 'test@example.com', passwordHash: 'hashed' };
    mockUserRepo.findByEmail.mockResolvedValue(user);

    const result = await authService.authenticate('test@example.com', 'pass');

    expect(result.success).toBe(true);
    expect(result.token).toBeDefined();
  });

  it('should_fail_when_user_not_found', async () => {
    mockUserRepo.findByEmail.mockResolvedValue(null);

    const result = await authService.authenticate('none@example.com', 'pass');

    expect(result.success).toBe(false);
    expect(result.error).toBe('INVALID_CREDENTIALS');
  });
});

测试需求：$ARGUMENTS

限制

• 仅在任务明确匹配上述范围时使用此技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果所需输入、权限、安全边界或成功标准不明确，停下来请求澄清。