verify-quality-integration-testing

name	verify-quality-integration-testing
description	集成测试——验证组件间交互和边界契约。当需要在单元测试之上验证跨组件/跨服务正确性，或提到"集成测试""integration""契约测试"

Integration Testing — 集成测试

入口/出口

• 入口: 单元测试覆盖了单组件逻辑，需要验证组件间交互
• 出口: 集成测试通过 + 边界契约验证
• 输出路径: 集成测试结果 → verify-workflow-review
• 指向: 集成测试通过后进入 /review
• 前置加载: CANON.md + build-quality-tdd/SKILL.md

何时不使用

• 只验证纯函数或单组件内部逻辑
• 跨组件/服务契约没有变化，已有集成覆盖仍有效
• 当前问题是 spec 缺失或代码质量审查，不是边界交互验证

Iron Law

``` 组件间交互必须在真实（非 mock）边界上验证。 单元测试通过但集成测试失败 = 系统不可靠。 没有集成测试的接口契约 = 猜测。 ```

何时写集成测试

必须写: API 端点（请求→响应）、数据库操作（ORM→真实DB）、跨服务调用、认证流程、文件上传/处理、Webhook 处理

不必写: 纯函数逻辑（单元测试）、第三方 SDK 内部行为、简单 CRUD 无业务逻辑

测试替身优先级

偏好顺序（从高到低）:
1. 真实实现  → 最高信心，能抓到真实 bug
2. Fake      → 依赖的内存版本（如内存数据库）
3. Stub      → 返回固定数据，无行为
4. Mock      → 验证方法调用 —— 仅用于无法控制副作用的边界

仅在以下场景 mock： 外部支付网关、邮件发送服务、第三方 API（无法控制、有速率限制或要花钱）。

绝不 mock 数据库。 用测试数据库或事务回滚。

测试结构

Arrange-Act-Assert (AAA)

describe('POST /tasks', () => {
  it('创建任务并返回 201', async () => {
    // Arrange: 设置测试场景
    const user = await createTestUser();
     payload = { : , :  };

    
     response =  (app)
      .()
      .(user.)
      .(payload);

    
    (response.).();
    (response...).();
    (response...).();

    
     saved =  db..(response...);
    (saved)..();
  });
});