成本感知的测试验证
减少冗余工作和输出，同时不削弱所需检查。选择更好的顺序可以节省执行时间；简洁的报告节省上下文，但不会使正在运行的测试更快。不要在没有测量的情况下声称节省。
规划并运行检查
- 在执行高成本测试套件之前，首先识别受影响的组件、风险、项目要求以及适当的检查。遵循明确的用户和项目要求，包括强制性检查。
- 首先完成核心变更和有意义的针对性回归覆盖。使用最窄的相关检查诊断并修复构建或行为失败。然后稳定受影响的集成或端到端场景。对于新的或更改的共享场景，与可用参考进行比较；分别验证并记录意图差异。
- 一旦变更和针对性检查稳定，根据需要运行所需的最终测试套件、静态检查和构建。仅在相关代码、依赖项、配置、环境和场景保持不变时复用成功结果。
- 修复后，重新运行受影响的检查。当影响范围广、依赖项变化、要求如此或正确性仍不确定时，重复运行广泛套件。不要为每次本地失败自动重复完整套件。
- 对于间歇性失败，保留第一次失败并单独重新运行测试；如果需要，串行运行其套件以调查干扰。报告未解决的稳定性问题，而不是将后续通过视为失败已修复的证据。
- 对于仅文档的变更，检查差异、相关链接和语法；仅当需要或相关时才运行应用程序测试。保持性能测量与可能扭曲结果的并发构建和测试隔离。
- 以合理的间隔轮询长时间运行的作业，而不是重复读取未更改的输出。避免仅仅为了检查进度而重新启动工作。
保持输出有用且受控
优先使用现有项目运行器或框架报告设施。将完整的 stdout 和 stderr 捕获到唯一且不覆盖的日志文件中，返回简洁摘要：命令结果和退出状态、持续时间、可识别的测试计数（包括跳过或忽略的测试）以及日志位置。失败时，包含失败案例名称和受限的诊断摘录；如果摘要不足以诊断，则检查完整日志的相关部分。切勿从部分套件计数推断整体成功：使用命令的实际退出状态，并在无法解析摘要时明确说明。保留启动错误、取消和信号行为。不要在现有运行器周围堆叠冗余包装器。
验证测试基础设施
创建或大量更改测试运行器、包装器或报告工具时，测试其结果的可信度。基于工具实际执行的操作以及隐藏或误报失败的风险选择案例。有用的案例包括：
- 成功套件后的后续失败仍应视为失败，具有正确的退出状态。
- 即使显示诊断受限，完整输出也应保留。
- 跳过、启动错误、无法识别的摘要和中断应被正确报告或传播（如果适用）。
测试可观察行为，包括与底层测试进程的边界。根据实际框架调整解析，避免仅重复实现的测试。这是对基础设施的验证，而不是要求为每个单独测试编写测试。不要仅仅因为使用了本技能就重写或重新测试已经可靠的现有工具。
编写诊断性测试
保持通过的测试安静，除非进度输出有用。失败应标识案例、预期和实际行为、相关参数以及任何随机种子。通过长度、不匹配位置、简短摘录或哈希描述大型负载，而不是完全转储所有内容。需要时启用逐次迭代细节或完整跟踪以进行诊断。显式标记跳过并附上原因，切勿将失败转换为成功退出。当处理有噪音的现有测试时改进它们，而不是仅仅为了格式而重写一个健康的测试套件。