用途
集成测试技能用于在单元测试覆盖单组件逻辑之后，验证组件间交互和边界契约是否正确。它在单元测试之上补充跨组件、跨服务的正确性验证，出口为集成测试通过并完成边界契约验证，随后进入 verify-workflow-review / review 环节。前置加载 CANON.md 与 build-quality-tdd/SKILL.md。
何时使用
当单元测试已覆盖单组件逻辑，需要验证组件间交互时使用。典型触发词包括“集成测试”“integration”“契约测试”。
何时不使用
- 只验证纯函数或单组件内部逻辑
- 跨组件/服务契约没有变化，已有集成覆盖仍有效
- 当前问题是 spec 缺失或代码质量审查，而非边界交互验证
何时必须写集成测试
必须写：API 端点（请求→响应）、数据库操作（ORM→真实 DB）、跨服务调用、认证流程、文件上传/处理、Webhook 处理。 不必写：纯函数逻辑（用单元测试）、第三方 SDK 内部行为、无业务逻辑的简单 CRUD。
测试替身优先级
从高到低：1. 真实实现（最高信心，能抓到真实 bug）；2. Fake（依赖的内存版本，如内存数据库）；3. Stub（返回固定数据，无行为）；4. Mock（验证方法调用，仅用于无法控制副作用的边界）。仅在外部支付网关、邮件发送服务、第三方 API（不可控、有速率限制或要花钱）时使用 mock。绝不 mock 数据库，应使用测试数据库或事务回滚。
测试结构与模式
采用 Arrange-Act-Assert（AAA）结构。API 集成测试应覆盖 Happy Path、Validation errors、Auth errors、Permission errors、Not Found、Edge cases（边界）。每个端点需覆盖：Happy → Validation → Auth → Permission → Not Found → Edge。
测试隔离与命名
数据库测试隔离首选事务回滚（快速、可靠），事务回滚不可用时使用测试数据库并清空。命名约定为：<动作> + <场景> + <预期>。
验证证据
输出或记录必须包含：输入/来源（读取的 spec、plan、代码、反馈或发布上下文）、执行动作（实际完成的检查、生成、修复、导出或发布步骤）、验证结果（命令、审查结论、产物路径、截图或人工确认）、阻塞/回退（未通过项、回退路径或需要 human partner 决策的问题）。
红旗与失败处理
以下情况应 STOP：集成测试 mock 了数据库；只覆盖 Happy Path；测试之间不隔离；集成测试调用外部真实服务；用 setTimeout 等待而非条件轮询 waitFor。失败处理：Happy Path 失败应阻塞先修复；Auth/Permission 失败属安全红线阻塞；数据库隔离失败需修复隔离策略；外部服务 mock 与真实不一致需更新或替换；未覆盖端点需在 review 前补充。
输出模板
提供 Integration Test Report 模板，包含覆盖范围、测试矩阵（端点 × Happy/Validation/Auth/Permission/Not Found/Edge）、测试替身使用、隔离策略、结果、失败详情、下一步。全绿则进入 /review，有失败则修复后重新运行，不跳过。
限制
资料未提供该技能的具体运行环境、安装命令、支持语言与框架、收费或价格信息、性能指标与平台限制，这些内容暂未提供。