auto-test-guard

name	auto-test-guard
description	在准备新增、修改、重写测试，修复 bug 并添加回归测试，执行 TDD，补覆盖率，调整测试断言、fixture、mock、snapshot 或测试层级时主动使用。用于自动约束测试设计质量，避免弱断言、重复用例、过度 mock、实现细节测试、无价值覆盖率测试和维护成本过高的测试。通常不需要向用户报告，除非测试策略风险会影响实现选择。

Auto Test Guard

写测试时自动使用这个护栏。不要生成报告，不要落盘，不要向用户声明已使用；只把它用于约束自己的测试设计。

本技能只管测试设计质量，不替代最终验证。完成改动后使用 auto-test-run 选择并执行验证范围。

先问

新增或修改测试前，快速确认：

• 这个测试保护什么行为契约？
• 失败时能说明什么真实风险？
• 附近是否已有测试覆盖同一行为？
• 当前层级是否是最低成本且足够可信的层级？

答不清楚就先读附近测试和相关实现；不要为了“有测试”而写测试。

应该写

• 测试名表达行为，而不是实现步骤。
• 断言用户可见结果、模块契约、状态变化、持久化结果或错误语义。
• 用代表性边界和真实场景，少量但高信号。
• 修 bug 时写最小回归测试，直接覆盖曾经坏掉的行为。
• 隔离随机、时间、网络、文件系统、数据库、LLM 等不稳定因素。
• DicePP 指令行为优先保护用户可见输入输出；不要只断言内部函数被调用。

不要写

• 只断言不抛异常、非空、长度大于 0 或布尔值为真。
• 只验证 mock 调用次数，却不验证行为结果。
• mock 掉真正要验证的核心协作。
• 复制生产逻辑来计算期望值。
• 为覆盖率机械测试 getter、setter、简单转发或私有实现细节。
• 与已有测试只差无意义参数。
• 用大而模糊的 snapshot 代替语义断言。
• 需要真实外部依赖却没有隔离、marker 或明确说明。

完成前

运行最小相关测试，或交给 auto-test-run 选择验证范围。若新增测试价值不足，就删除、合并或重写它。

只有在这些情况才告诉用户：没有新增测试的原因、放弃了低价值测试方案、选择较重测试层级的理由、需要真实外部依赖或高成本测试确认。