Spring 集成测试与 Testcontainers：真实依赖怎样可重复验证

高谷深陵大约 9 分钟约 2568 字

Spring 集成测试与 Testcontainers：真实依赖怎样可重复验证高清原图

贯通 TestContext、测试切片、Context Cache、事务假阳性、动态属性和 Testcontainers 生命周期。

Spring 的 TestContext Framework 管理上下文缓存、注入和测试事务；Testcontainers JUnit Jupiter 明确区分静态共享与实例级容器生命周期。

集成测试证明的是装配后的协作

单元测试可以证明 repository 收到正确参数，却不能证明实体映射、事务代理、序列化配置、SQL 方言和数据库约束协同正确。集成测试选择最小但真实的边界：数据切片验证 ORM 与数据库，MVC 切片验证映射和错误协议，全上下文验证条件装配与跨层事务。所有测试都启动完整应用会拖慢反馈，也让失败难定位。

测试切片不是“假的集成”，而是明确排除无关 Bean。若被测行为依赖安全过滤链、事务事件或自定义 converter，就必须把它纳入或提升到全上下文；不能为了让测试启动而 mock 掉正在验证的机制。

Context Cache 的 key 是套件性能模型

Spring 按配置类、Profile、动态属性、Bean override 等合成 MergedContextConfiguration 作为缓存键。每个测试随意写不同 property 或 mock Bean 会制造大量独特上下文，套件从一次启动退化为逐类启动。共享稳定测试配置、按真正边界分组，观察 cache hit/miss 与启动时间。

@DirtiesContext 用于确实污染容器状态的少数测试；把它当清理万能键会隐藏可变单例并摧毁缓存。测试若修改静态变量、系统属性、时区或线程池，也不会被重建 ApplicationContext 自动修好，必须显式恢复。

测试事务可能制造“提交成功”的假象

默认回滚让数据清理方便，但测试方法、业务服务和断言在同一事务时，未 flush 的 ORM 状态、延迟约束、after-commit 监听器与另一连接可见性都未被验证。需要 flush/clear、显式提交或非事务测试，再从新连接读取权威结果。

异步线程和抢占式超时不继承测试事务，可能真的提交，即使主线程最后回滚。反向实验让业务发布 after-commit 事件并从独立连接查询，证明测试覆盖提交边界而不是只看一级缓存。

容器生命周期决定隔离与反馈速度

静态 @Container 在一个测试类内共享，实例字段按方法重启；套件级共享能减少启动，但数据、Topic、Schema 和时钟必须隔离。容器 ready 不是端口已开放，而是协议健康、初始化脚本完成且迁移成功。动态端口通过 @DynamicPropertySource 注入，不能硬编码本机地址。

Testcontainers 的 reusable 模式仍属实验能力且不适合 CI。CI 使用可清理的确定生命周期、固定镜像 digest 或版本、资源上限和失败日志采集。容器替代了外部安装差异，却没有替代应用数据清理与并发隔离。

测试切片的缺失 Bean 必须是有意识的

@WebMvcTest 通常不加载完整数据层与业务装配，@DataJpaTest 默认聚焦 JPA 并可能替换数据源，@SpringBootTest 才接近完整应用。每个切片列出真实组件、替身和排除项；如果安全、Jackson Module、异常处理或事务事件决定协议，就显式导入并增加一个全链路测试验证没有漏装。

Bean override 会进入 Context Cache key。每个类定义不同 @MockitoBean 不只改变行为，也会碎片化缓存；更稳的做法是按相同协作边界分组，或在无需 Spring 时退回纯单元测试。启动日志的 Context id、cache hit/miss 和 Bean 条件报告应在慢套件诊断中可见。

数据初始化要与 migration 同源

容器启动后先运行与生产相同的 Flyway/Liquibase migration，再用最小 SQL、Repository 或 API 准备数据。把完整 schema.sql 复制到 test resources 会逐渐偏离生产。Fixture 插入必须尊重真实约束；如果为了方便禁用外键，测试就不能证明删除与引用行为。

每个测试使用事务回滚、truncate、独立 schema 或容器重建之一，选择依据是提交语义和并发。truncate 需要处理外键顺序并禁止与并行用例共享；独立 schema 提高隔离但增加 migration 成本；每方法容器最强隔离却最慢。用测量选择，不把一种策略硬套全仓。

容器不是黑盒等待器

镜像固定正式版本或 digest，启动等待数据库查询、Broker 元数据或应用健康，而不只 wait for listening port。初始化失败采集容器日志、inspect、映射端口、网络和 migration 输出。测试结束检查线程、连接和容器清理，避免 Ryuk 或 JVM 退出才回收成为本机泄漏。

CI 无 Docker 权限或镜像仓库暂不可达属于基础设施失败，报告要与断言失败区分。离线缓存不能允许未验证的旧镜像冒充目标版本；镜像更新触发兼容套件，而不是在任意 PR 中漂移。

先写证明对象，再选择测试层

测试替身越多，速度越快但与真实运行的距离越大；真实依赖越多，协议证据越强但状态和资源更难隔离。组合策略应让同一高风险结论至少由两种不同失败模式的证据支持，例如单元验证版本条件，真实数据库验证条件更新确实只影响一行。

失败必须保存成可重放状态

失败包至少包含测试 id、代码提交、依赖版本、seed、时钟、Locale、执行顺序、资源标识、容器日志、线程信息和业务见证。结果未知与产品断言失败分开统计；基础设施掉线不能自动归为产品缺陷，产品超时也不能全部甩给 CI。

可维护测试也需要性能、数据和安全边界

套件容量模型包含用例数、上下文/容器启动、数据初始化、并发 worker、日志与制品体积。并行度超过数据库连接、CPU 或容器资源只会增加尾延迟和 flaky；先量测各阶段临界路径，再决定共享、分片或下沉。

演进遵循“读取端先兼容、写入端后切换、旧证据归零再删除”。框架升级先固定当前发现数、执行顺序、上下文 key 和报告格式，再迁移版本；不能把升级造成的少跑测试误当提速。

用两个 Java 17 模型固定测试见证

模型不依赖测试框架或外部服务，只把边界输入、状态转换和期望见证压成确定输出；真实项目再用 JUnit、Mockito、Spring、容器或 WireMock 驱动同一不变量。

javac --release 17 -Xlint:all -Werror examples/backend-development/testing/spring-integration-testcontainers/ContextCacheKeyDemo.java examples/backend-development/testing/spring-integration-testcontainers/TransactionVisibilityDemo.java
java -cp examples/backend-development/testing/spring-integration-testcontainers ContextCacheKeyDemo
java -cp examples/backend-development/testing/spring-integration-testcontainers TransactionVisibilityDemo

contextKeys=3 hits=2 misses=1 dirtyReloads=1 cacheSize=2
testRollback=true asyncCommitVisible=true falsePositivePrevented=true cleanupVerified=true

实际测试若改变输出，必须解释是业务规格、测试层、Fixture、调度还是门禁发生变化；禁止用放宽断言或无限重试吸收差异。