testing-boss

测试指南

选择能够暴露所改行为失效的测试。在能够观察该不变量的最低层使用现有测试套件；优先复用 fixture 和工具，再创建新文件。

• 断言可观察的结果，而不是 mock 行为或实现结构。将 mock 限定在单元测试的 I/O 边界；对于集成层面的声明，使用真实的集成证据。
• 当测试暴露回归时，修复生产代码。只有在有证据表明测试的契约有误或已被有意更改时，才修改错误的测试；保留有效的覆盖。
• 现有测试或更严格的构建、代码生成、链接和渲染检查可能已经负责验证该不变量。若没有真实的产物契约，且负责验证的关卡并不足以满足要求，就不要添加说明文档、CSS、生成输出、配置或快照测试。
• 覆盖率和变异分数有助于发现盲点，但不能取代行为判定依据。不要仅为了测试而添加生产代码分支或方法。
• 运行受影响的检查，然后运行项目的交付关卡。对于未更改的输入，复用已有结果；只有出现失败、相关修改或未解决的风险时，才扩大检查范围。让回归复现与故障相匹配；如果已有红绿证据，就避免重复走流程。

按问题查阅参考资料

遇到问题时，阅读相关章节及其契约依赖；Agent 编写测试本身并不意味着必须查阅所有参考资料。

问题	参考资料
哪一层或哪个测试套件负责验证该不变量？	references/foundations.md
选择器、等待、数据或 mock 应如何处理？	references/patterns.md
为什么测试不稳定，或因错误原因而通过？	references/antipatterns.md
应如何评估 Agent 生成的测试？	references/ai-writes-tests.md
应如何处理不稳定性或契约、属性、变异检查？	references/ci-automation.md
应如何评估 LLM/Agent 的结果？	references/llm-eval.md

references/sources.md 收录了支持性来源。完成情况的证据可以是简明的命令与结果摘要；除非任务的产物契约有要求，否则无需另附报告。