用途：这是一份测试编写指南，用于在新增功能、修复缺陷或需要测试时统一团队做法，目标是让测试验证行为而非实现细节，并在手工测试前提供可信度。
主要能力与原则：
- 模拟外部服务、使用真实夹具：始终模拟第三方网络服务，始终使用基于真实数据的夹具；夹具须去除个人信息（如 foo@example.com、user-123），先抓取真实 API 响应再脱敏；测试中绝不发起真实网络请求。
- 优先集成测试：侧重端到端风格，验证输入与输出而非实现细节，测试公开接口而非内部方法；纯函数的边界情况可用单元测试，但集成测试优先；若重构导致测试失败而行为未变，说明测试与实现耦合过紧。
- 减少边界用例：不必测试问题的每种变体，充分覆盖常见路径，跳过穷举式输入排列与低价值边界用例，每类输入一个代表性测试通常足够。
- 缺陷必须补回归测试：识别缺陷后始终添加能捕获它的测试，该测试在修复前应失败、修复后应通过，并命名清晰以记录该缺陷。注意回归测试针对非预期的破坏行为（缺陷），而非有意变更；有意的功能移除、弃用或破坏性变更不需回归测试。
- 覆盖每个用户入口点：每个客户/用户入口点至少有一个基础测试，如 CLI 命令、API 端点、公开/导出函数，先测常见（顺利）路径，以证明入口点可用。入口点指公开接口，内部/私有函数不算入口点。
- 测试先于手工 QA：测试是在手工测试前验证功能是否可用的方式，先写或与代码同步写测试；若无法测试，应重新考虑设计。
技术细节：文件组织上尽量将测试与源文件放在一起，并使用项目标准测试文件命名约定。测试隔离要求每个测试独立运行、不互相影响，文件操作使用临时目录，结束后清理资源。无副作用的纯函数无需特殊设置，直接测输入输出。
提交前清单：新入口点至少有一个顺利路径测试；缺陷修复（非有意变更）包含回归测试；外部服务被模拟且夹具已脱敏；测试验证行为而非实现；测试之间无共享状态。
限制：资料未提供具体的测试框架、命令、目录结构示例或语言相关配置，暂未提供。