第3章 集成测试会诊室：拼装接缝的验证

本章要回答的三个问题：单元里各自都绿灯，为什么拼起来还是红？集成测试到底测什么、按什么顺序拼装才能最快揪出接缝问题？环境、数据库和测试数据这三样东西，怎么管才能不拖后腿又不互相污染？

为什么会有这一章

第 2 章把单个零件测得很干净，可真实事故几乎从不在单个零件里爆，而是发生在"两个都正常的零件对接的那一头"：A 模块认为订单金额是整数，B 模块当字符串拼接；一个服务把错误码定义为 200，另一个服务期待 404。单元测试天生看不见这些——因为它们的资产恰恰是互相隔离。这一章把你拉出隔离区，带进会诊室：先讲集成测试凭什么值得花更贵的成本，再讲四种拼装顺序（大爆炸、自顶向下、自底向上、三明治）各自的危险区，接着解决最恼人的两件事——测试环境和测试数据，最后给出一张"挑战与解药"对照单。它和第 2 章正好是一对：那边负责把零件测亮，这边负责把接缝测亮。

读完能解决什么

• 能区分"单元测试证伪"与"集成测试证伪"的边界，知道哪类缺陷只有集成层才拦得住。
• 能根据项目结构在四种集成策略里做取舍，并说出每种策略最怕的死角。
• 能为集成层搭建可控环境，用内存库或容器把外部依赖"关进玻璃房"。
• 能为集成测试设计数据初始化与清理的生命周期，杜绝测试间互相污染。
• 面对慢、脆、贵这三大集成测试痛点，能拿出至少三套对治手段而不是抱怨。

各节怎么分工

先决条件

• 完成第 2 章，理解替身的使用边界，知道何时该"把替身换回真依赖"。
• 能读懂简单数据库表结构和一次接口请求。
• 了解 Docker 容器的最基础概念（镜像、容器、端口），不需要会写复杂编排。

往下走到哪

第 3 章讲清楚"拼接要怎么测"，但还没回答"到底单件和拼接的比例怎么定、某段代码该归哪层"。这正是第 4 章红绿灯分诊台的分工——它拿第 2、3 章的两套套路做裁决，决定一盏应该亮的灯到底装在哪层更划算。读完第 3 章后进入第 4 章，你既有零件经验又有拼装经验，分诊才有依据。

本章知识点清单

• 能用"离外部世界近不近、要不要真依赖"一句话，判断一段逻辑该归集成层而非单元层。
• 能列出集成测试拦得住、单元层拦不住的三类缺陷：接口不匹配、数据不一致、进程与协议层问题。
• 能在四种集成策略（大爆炸、自顶向下、自底向上、三明治）间做取舍，并说出各策略最怕的死角。
• 能根据系统面貌（模块多少、接口复杂、核心在底层还是上层）选对策略并说明理由。
• 能在内存库与 Docker 容器之间按"提速优先还是保真优先"做环境选型。
• 能按要求"跑前重置已知状态、跑后清理"设计测试数据的生命周期，杜绝跨用例互相污染。
• 能对集成测试慢、脆、贵三大痛点各给出一套可操作解药，而非停留在抱怨。
• 能用一根"以拦住单测拦不住的真实缺陷来计价"的评估杆，决定一条集成用例值不值得保留。

一章一图：接缝怎么被照亮

这张图回扣本章主题：集成测试照的从来不是单件内脏，而是两个正常单件之间的那条接缝。灯红通常意味着"口径漂移"——接口、数据、协议其中之一在两头对不上，这正是第 3.1 节讲到集成层独有的价值。