TDD 红灯阶段测试生成

要解决什么问题

在 TDD 的红灯阶段，常见失误是测试写得太晚、只测 happy path，或者一跑就绿——说明测的是实现细节而不是行为。真正有用的红灯测试应当在尚未实现功能时就失败，且失败原因明确：缺行为，而不是 import 写错或 fixture 互相污染。

技能如何工作

本技能把「识别行为 → 写失败测试 → 验证失败原因」收成可重复流程，并通过子代理 unit-testing::test-automator 生成测试骨架。

核心能力包括：

• 行为覆盖：正常路径、空值/null、边界值、异常与（如适用）并发
• 测试结构：Arrange-Act-Assert、should_X_when_Y 命名、隔离 fixture
• 失败验证：运行必失败、诊断信息可读、避免级联失败
• 分类意识：单元 / 集成 / 契约 / 属性测试，并按 Jest、pytest、Go、RSpec 等框架给出模式

操作步骤可概括为：先列出行为、约束与边界；再生成定义预期结果的失败测试；确认失败来自缺失实现；最后记录如何运行并核对失败形态。

适用边界与注意点

不适用于绿灯或重构阶段、纯性能基准，或必须在生产环境执行的测试。红灯阶段应隔离测试数据，并尽量避免不稳定的外部依赖，以免把环境抖动误判成「行为未实现」。