单元测试与集成测试的边界：测试金字塔的实践

测试策略决定了交付速度的上限

多数团队的测试困境不是「写得不够多」，而是「写错了层」——把本该在单元测试覆盖的逻辑放进集成测试（每次跑测试都起数据库、起容器），导致测试套件越跑越慢，团队从「每次提交都跑」退化到「上线前才跑」，测试失去了反馈环的价值。测试金字塔（单元多、集成少、端到端最少）不是理论，是交付效率的工程约束。

一、三层测试的分工边界

单元测试：逻辑验证的主战场

• 测试对象：单个函数/类的逻辑——条件分支、边界值、错误处理、状态转换；
• 运行依赖：零外部依赖——数据库、网络、文件系统全部 mock/stub；
• 速度标准：全量测试 < 10 秒——超时的测试套件会被绕过，速度就是生命；
• 数量占比：约 70-80%。

写什么：纯逻辑函数（计算、解析、验证）、状态机转换、错误分类。不写什么：需要真实数据库行为的逻辑（事务隔离、锁竞争）。

集成测试：边界正确性的保障

• 测试对象：模块间接口——服务层+持久层、消息生产+消费、缓存+数据库一致性；
• 运行依赖：真实依赖（Docker 起数据库、消息队列），本地或 CI 环境；
• 速度标准：单个 < 10 秒，全量 < 10 分钟；
• 数量占比：约 15-25%。

写什么：ORM 映射与查询行为、事务与回滚、缓存失效策略、消息序列化兼容。不写什么：纯业务逻辑（该在单元测试覆盖）、完整用户流程（该在端到端测试覆盖）。

端到端测试：关键路径的最后防线

• 测试对象：用户关键路径——注册登录、下单支付、退款等核心流程；
• 运行依赖：完整环境（或多环境共享）；
• 速度标准：不追求快，追求准——跑全套可能要小时级，所以只在关键路径部署；
• 数量占比：约 5-10%。

二、决定「写在哪层」的三个问题

写测试前依次问：

1. 这个测试断言的是逻辑还是连接？——逻辑→单元测试；连接→集成测试；
2. mock 的成本是否超过了测试本身的价值？——如果为了写单元测试要 mock 十个依赖，说明这段代码的边界设计有问题，先重构再测；
3. 这个测试失败时能帮你定位什么？——能定位到具体逻辑 bug 的放单元层；只能告诉你「哪里断了」的放集成层；只能告诉你「用户操作失败了」的放端到端层。

三、实践准则

1. 新增代码测试先行：至少单元层覆盖新逻辑——「以后再补」的测试永远不会被补；
2. 测试数据自建自毁：每个测试自己准备数据、自己清理，不依赖「数据库里已有的那条记录」——环境依赖让测试在别的机器上随机失败；
3. mock 边界写在模块边界上：mock 外部服务（下游 API、消息队列），不 mock 内部模块——mock 太深会导致测试只验证了 mock 本身；
4. 集成测试用 Testcontainers：真实数据库跑在容器里，每次干净启动，比共享测试库稳定得多；
5. CI 分层执行：单元测试在每次 PR 触发（秒级反馈），集成测试在合并前跑，端到端在每日定时跑——反馈速度与测试深度成反比。

四、验收

测试策略的健康度看三个数：覆盖率趋势（单元测试覆盖率不掉，说明新代码在补测）、套件执行时间（单元套件 < 10s 是底线）、漏出缺陷（被测试覆盖了但线上仍出的 bug——它们通常集中在「层边界」上，指向集成测试的缺口）。

测试金字塔的本质：把验证成本压在最便宜的那层（单元），越往上层测得越准但越贵、越少。倒金字塔（大量端到端、少量单元）的团队，不是测试做得多，是每次提交都在等一套又慢又脆的测试套件——反馈慢了，质量就不会好。