企业官网建设流程全解析

name: tdd-workflows-tdd-red
description: “Generate failing tests for the TDD red phase to define expected behavior and edge cases.”
risk: critical
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 命名约定
   • 无相互依赖的隔离夹具

2. 行为覆盖

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

3. 失败验证

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

4. 测试类别

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

框架模式

JavaScript/TypeScript（Jest/Vitest）

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

Python（pytest）

• 使用适当作用域的夹具（fixtures）
• 使用 Parametrize 处理多个测试用例
• 使用 Hypothesis 进行基于属性的测试

Go

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

Ruby（RSpec）

• 使用let进行惰性加载，let!进行急切加载
• 使用上下文（Contexts）处理不同场景
• 使用共享示例（Shared examples）处理公共行为

质量检查清单

• 可读的测试名称记录意图
• 每个测试一个行为
• 无实现泄漏
• 有意义的测试数据（不是 ‘foo’/‘bar’）
• 测试充当活文档

要避免的反模式

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

边界情况类别

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

输出要求

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

验证

生成后：

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

示例（最小）

// auth.service.test.tsdescribe('AuthService',()=>{letauthService:AuthService;letmockUserRepo:jest.Mocked<UserRepository>;beforeEach(()=>{mockUserRepo={findByEmail:jest.fn()}asany;authService=newAuthService(mockUserRepo);});it('should_return_token_when_valid_credentials',async()=>{constuser={id:'1',email:'test@example.com',passwordHash:'hashed'};mockUserRepo.findByEmail.mockResolvedValue(user);constresult=awaitauthService.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);constresult=awaitauthService.authenticate('none@example.com','pass');expect(result.success).toBe(false);expect(result.error).toBe('INVALID_CREDENTIALS');});});

测试要求：$ARGUMENTS

局限性

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