test

测试

为指定行为编写或强化测试。如果任务只是运行已知测试套件，请直接使用现有测试；此技能并非必需的包装层。当测试能区分可接受结果与看似合理的失败时，才算有用，而不只是执行实现。测试通过是调用方决策的依据，绝不是测试作者批准合并的依据。

模式

模式	适用场景	结果
generate	现有行为需要测试	有用的测试及针对性／套件结果
coverage	调用方要求查找或填补缺口	前后覆盖率、有价值的测试及剩余风险
tdd	以测试优先的方式开发新行为	实际预期的 RED、实现、通过和重构
strategy	调用方只要求测试设计	在现有讨论中列出优先级风险和建议检查项

默认使用 generate；模式和范围是技能提示词的选项，不是臆造的 CLI 标志。覆盖率阈值由调用方或仓库决定。

关键约束

• 断言承诺的效果。 在行为边界检查承诺的状态变化、出站调用或数量；除非存储结构本身就是契约，否则应通过产品自身的读取路径读回存储的记录。精确预期值取自字面值、示例或规范，绝不能取自实现自身的公式或模拟对象的答案：例如，对 50 打 8 折，应断言结果为 40。仅有状态码、返回对象或没有抛出异常，并不能证明行为；如果代码返回空结果或默认结果，测试是否仍会通过？拒绝测试应断言其名称所声称的错误，因为其他守卫也可能拒绝相同输入。
• 回归测试只有在缺陷存在时会失败，才能证明问题。 证明它在修复前的代码上会失败（见 Mutation-kill proof），并通过产生问题报告的调用方、顺序或状态来验证，而不只是在已修改的代码行上验证。在此之前，应将其证明状态报告为“未展示”；仅通过还不能算证明。
• 根据可接受的可观察行为推导测试用例；优先复用对话、bead、规范或现有契约中的示例，再自行构造新例。保留既有领域名称；不要通过重命名测试来统一有界上下文中的术语。
• 使用仓库采用的框架和实际检查流程；避免测试意外依赖时间、顺序和共享状态。
• 对现有正确行为编写的测试即使一开始就通过，也是合理的；在修改代码前，可用这类测试固定尚未测试的代码，并将异常结果标记为疑似缺陷。绝不要捏造 RED 结论，也不要更改验收标准来掩盖产品缺陷。
• 如果已获授权，可修复发现的缺陷；否则应报告复现步骤和发现。不要通过删除或弱化测试来掩盖问题。

预言强度层级

已知时，优先使用精确的可观察值或错误。如果属性或不变量比单个示例更忠实地表达契约，则使用它们。差分一致性需要可信且独立的参考。冒烟检查只能证明它所观察到的内容，不能单独确立精确行为。当正确性取决于含义（例如摘要或排名）时，数量只是代理指标；应按照 证明忠实度 中的方式评估。通过原生交接说明重要的预言局限，无需创建工作表或强制要求报告。

变异杀死证明

证明一项重要的新行为检查能够捕获它声称要防范的缺陷。真实的修复前 RED 或复现通常就足够了。如果回归测试是在修复后编写的，请在修复前的版本上运行它（在隔离副本中撤销修复），或使用安全且有针对性的负向对照。只有在这能消除对判定标准的实际疑虑时才进行变异，然后还原并验证候选版本。不要要求每个表格行或每个新测试都进行一次变异实验。只有在确认副本包含此候选版本的提交和未提交更改，且仅有那一处编辑时，才相信撤销或变异结果；从 HEAD 创建的工作树可能不包含修复或测试。切勿变异共享检出版本。

测试框架健康底线

确认运行器已完成、预期测试确实运行，并且断言能观察到承诺的行为。以运行器的退出状态为准，而不是它打印的输出；通过管道时保留该状态（pipefail）：make test | tail 报告的是 tail 的状态。会编辑已跟踪文件的检查改变了受测对象；请报告该编辑。将崩溃、输出截断、意外跳过或排除项报告为缺口。运行器的测试发现或失败报告机制发生变化时，在相信通过结果之前，须通过同一机制运行负向对照。如果这项更改本身是替代真实运行的检查，还要确保其上下文与所保护的内容一致（证明保真度）。每次编辑时，无需重新证明未变更且健康的运行器。

工作流

1. 阅读已接受的示例和相关公共接口。对于小型更改，一个有区分度的示例可能就足够；还应添加可能推翻验收结论的错误和边界情况。.feature 文件是可选的；如果仓库已使用场景到测试的注释，请保持这些注释，并使用仓库的场景覆盖检查器。如果多种记录类型支持不同操作，请依据已接受的领域规则推导有意义的类型／操作组合，并检查其承诺的最终状态。不要臆造不可能的组合，也不要根据相近类型的通过测试推断某类型的结果。一个表格测试可以覆盖许多组合；无需为每个单元格单独创建产物或测试。在 unchecked 下报告相关的未检查组合。如果这些类型都应消失，共用移除代码是合理的；但如果观察到的最终状态与已接受的含义相矛盾，那就是缺陷，例如撤回操作本应保留为非活动状态的记录，却将其删除。
2. 找到所属测试套件和范围狭窄的基线。对于缺陷，在修改代码前确定由哪个测试来证明修复；如果没有可触达所报告调用链的接缝，就不要编写更浅层的替代测试（证明保真度）。只有在会改变测试选择时，才使用 Domain 的标准。仅在 coverage 模式或现有仓库要求下衡量广泛覆盖率。
3. 编写最精简的测试，通过稳定接口观察承诺的结果：即调用方使用的入口点。不要添加仅供测试调用的导出、标志或钩子（时间、随机性或外部边界接缝除外）；不要在单元内部模拟协作者；对于此处编写的、会被保持行为不变的重写破坏的测试，将其移至该接口；将现有此类测试报告为重写候选项。在 tdd 模式下，先运行测试并要求其因预期行为缺失而失败，然后在测试通过的状态下实现并重构；每次只处理一个测试，每个后续用例都根据上一轮结果选择。
4. 编辑期间运行针对性检查，并在交接前运行相关的集成流程；只有风险发生变化、检查失败或仓库政策要求时，才扩大检查范围。
5. 与原先已接受的示例对比。实现后新增的测试可以作为补充，但不能取代这些示例。

专项参考

仅加载与主题相关的指导：

• 公共兼容性契约：conformance-harnesses
• 解析器与恶意输入：fuzzing
• 快照：golden artifacts 和 update strategy
• 不变量：metamorphic testing
• 服务集成：real-service E2E
• 选定的用户旅程：exploratory QA
• 经授权的套件维护：suite audit
• 缺陷证明的放置位置、替身检查和判定输出：proof fidelity
• CLI/API 失败信号和结果不确定的写入操作：error recovery
• 计时、共享状态或并发故障：difficult-failure experiments
• 工作负载基准与候选方案比较：subject performance

输出规范

测试应放在仓库采用的语言原生位置。事实和限制应写入现有交接文档：

tests:     <file::name> -> <behavior and exact values it asserts>
proof:     <each important new test> -> how it was shown to fail on its defect:
           pre-fix RED | reverted-fix run | negative control | not shown
commands:  <exact command> -> <result>
harness:   <runner completed; how many ran; skips or exclusions>
defects:   <discovered defect and reproducer, or none>
unchecked: <material behavior no test covers>

只有在收到请求或声明的使用方要求时，才在其选定位置持久化覆盖率或其他报告；不要自动生成 .agents/ 输出。事实性通过结果只是调用方进行合并或审核决策的输入，并非测试作者有权做出的 PASS 判定。

示例：对于重复投递的 Job，应断言返回已完成的结果，且外部副作用仅被调用一次。若没有这些断言，仅凭覆盖率提升无法证明该行为。

本指南中的原创示例参考了 Matt Pocock 的工程技能，并结合了 AgentOps 现有的验收与证据边界。