integration-testinglisted

# 集成测试 ## 何时用 - 编写涉及数据库、HTTP 外部服务、消息队列等真实 I/O 的测试时。 - 发现单元测试全绿但上线后接口出错——说明 mock 掩盖了真实集成问题。 - 评审别人测试代码时发现"测试全是 mock,没有一处真实调用"。 - 准备把新服务接入现有系统,验证契约是否匹配。 ## 核心规则 ### 1. 测关键路径的真实集成,不全 mock 掉失去意义 **规则：** 对数据库读写、HTTP 调用、队列消息等关键 I/O,必须至少有一层测试走真实实现,而非全部替换为 mock。 **为什么：** AI 写测试时习惯把所有外部依赖都 mock 掉,代码看起来很"干净",但这样只是在测试自己写的 mock 实现,而非系统的真实行为。常见事故:mock 掉了 ORM 层,测试全绿,上线后因字段类型不匹配导致 `IntegrityError`。mock 掉了 HTTP 客户端,测试通过,生产环境 API 已改版本导致响应结构变了。 **怎么做：** - 用 Testcontainers 或本地 Docker Compose 启动真实 Postgres/Redis/Kafka 实例跑测试。 - HTTP 外部依赖用 WireMock / msw 录制真实响应,而非手写假数据结构。 - 单元测试 mock 细节,集成测试只 mock 不可控的第三方(如支付网关),其余走真实路径。 --- ### 2. 测试隔离:每个用例自带数据、用完清理,不依赖执行顺序 **规则：** 每条集成测试必须独立准备自己的数据,测试结束后恢复初始状态,与其他用��无任何隐式依赖。 **为什么：** AI 生成的测试常复用全局状态——在 `beforeAll` 里插一条记录,多个 `it` 块都读它。当测试并行跑或顺序变化时,用例之间互相污染,出现"单独跑通,全量跑挂"的薛定谔测试。常见事故:两个用例都插了 `email = 'test@example.com'` 的用户,唯一索引冲突导致其中一个随机失败。 **怎么做：** - 每条 `test` / `it` 内部完成数据 setup,通过事务回滚或 `afterEach` truncate 清理。 - 避免 `beforeAll` 里的共享数据被多个用例修改。 - 用随机后缀或 UUID 生成测试专用标识符,防止并发冲突。 --- ### 3. 用真实或贴近真实的依赖(测试容器),不假设外部服务永远在线 **规则：** 集成测试依赖的外部服务要通过受控手段启动(Testcontainers、Docker Compose),而非假设 CI/本地某个固定地址永远可用。 **为什么：** AI 有时会在代码里硬编码 `localhost:5432` 或 `redis://ci-server`,假设环境已就绪。这导致:换一台机器跑就失败、CI 服务重启后测试挂掉、本地没有 Redis 的同事根本无法运行测试。测试变成"只在我电脑上能跑"的代码。 **怎么做：** - 用 `testcontainers` 库在测试套件启动时自动拉起所需服务,结束时销毁。 - 连接字符串从容器实例动态获取,不硬编码。 - 若 CI 已有服务,通过环境变量注入地址,代码里优先读环境变量再回退到容器。 --- ### 4. 断言可观察结果与副作用,避免对实现细节断言导致脆弱 **规则：** 断言系统对外可观察的状态(数据库里写了什么、HTTP 响应返回了什么、消息队列里有什么),不断言内部函数