该技能是一份测试编写规范，用于在添加新功能、修复缺陷或需要编写测试时提供指导。以下是其要求遵循的原则与技术规范。
一、用途与核心原则
-
模拟外部服务，使用真实固定数据：始终模拟第三方网络服务；始终使用基于真实世界数据的固定数据（fixture）。固定数据必须清除个人身份信息（PII），可使用 foo@example.com、user-123 等假数据；先捕获真实 API 响应，再对其进行脱敏；测试中绝不发起真实网络调用。
-
优先集成测试而非单元测试：聚焦验证输入与输出的端到端式测试，而非实现细节；测试公开接口，而非内部方法；单元测试对纯函数的边界情况有价值，但集成测试优先；如果重构导致测试失败而行为未变，说明测试与实现耦合过紧。
-
尽量减少边界情况测试：不要测试问题的每一种变体；彻底覆盖常见路径；跳过穷举式输入排列；跳过增加维护负担却无价值的罕见边界情况；每类输入通常一个代表性测试即可。
-
为缺陷始终添加回归测试：发现缺陷时，始终添加本可捕获该缺陷的测试；该测试应在修复前失败、修复后通过；以描述性名称记录该缺陷；这能防止同一缺陷再次出现。注意：回归测试针对无意破坏的行为（缺陷），而非有意的变更；有意的功能移除、弃用或破坏性变更不需要回归测试，因为这些是设计决策而非缺陷。
-
覆盖每个用户入口：始终为每个客户/用户入口至少提供一个基础测试，包括 CLI 命令、API 端点、公开/导出的函数；先测试常见/正常路径；这能证明入口点至少可用。注意：“入口点”指公开接口——导出的函数、CLI 命令、API 路由；内部/私有函数不是入口点，即使它们处理面向用户的标志或选项。测试入口点；内部函数通过这些测试获得覆盖。
-
测试先于人工 QA 验证：测试是在人工测试前验证任何功能是否正常工作的方式；先写测试或与代码同步编写，而非事后补写；如果无法测试，应重新考虑设计；测试通过应能提供发布信心。
二、技术规范
文件组织：尽可能将测试与源文件放在一起；使用项目标准的测试文件命名约定。
测试隔离：每个测试必须独立运行且不影响其他测试；文件操作使用临时目录；完成后清理资源。
纯函数测试：对于无副作用的纯函数，无需特殊设置，直接测试输入与输出即可。
三、提交前检查清单
新的入口点至少有一个正常路径测试；缺陷修复（而非有意变更）包含回归测试；外部服务已用脱敏固定数据模拟；测试验证行为而非实现；测试之间无共享状态。