多模块联合集成测试属于集成测试而非单元测试，需启动真实Spring上下文、连接嵌入式资源、验证跨模块协作；应使用@SpringBootTest、TestRestTemplate、嵌入式中间件等，并避免mock与真实依赖混用。
Java 中的“多模块联合集成测试”不是单元测试的职责，而是集成测试的范畴。单元测试只验证单个类或方法的逻辑正确性，不涉及模块间调用、外部依赖或真实环境交互；一旦需要验证多个模块（如 service + dao + controller）协同工作，就必须升级到集成测试层级。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
明确区分：单元测试 vs 集成测试
• 单元测试使用 JUnit + Mockito，所有外部依赖（数据库、HTTP 调用、其他服务）必须被 mock，保证快速、隔离、可重复。
• 多模块联合验证必须脱离 mock，启动真实上下文（如 Spring Boot 应用上下文），连接真实或嵌入式资源（H2 数据库、TestRestTemplate、嵌入式 Kafka），这才是集成测试——通常以 *IT 或 *IntegrationTest 命名，放在 src/test/java 下独立包中，且需配置 Maven 的 failsafe-plugin 专门执行。
实现多模块联合集成测试的关键步骤
• 使用 @SpringBootTest 启动最小化但真实的 Spring 上下文，自动装配跨模块 Bean（如 UserService 调用 UserRepository，再触发 OrderService 逻辑）。
• 搭配 @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.ANY) 确保使用 H2 替换生产数据库，避免环境干扰。
• 对 Web 层联合验证，用 WebEnvironment.RANDOM_PORT + TestRestTemplate 或 @AutoConfigureMockMvc 发起真实 HTTP 请求，观察 controller → service → repository 全链路是否连通。
• 若模块间含异步通信（如 RabbitMQ、Kafka），启用嵌入式中间件（spring-rabbit-test 或 spring-kafka-test），并用 CountDownLatch 或 awaitility 等待消息消费完成。
避免常见误区
• 不要在单元测试类里 new 多个 Service 实例并手动调用——这仍是单元测试思维，未验证 Spring 容器管理、事务传播、AOP 代理等运行时行为。
• 不混用 @MockBean 和真实数据库：@MockBean 会覆盖容器中的真实 Bean，导致“看似集成实则隔离”，失去联合验证意义。
• 不跳过测试数据准备：用 @Sql 或 Flyway/Testcontainers 初始化一致的测试数据集，确保每次执行状态可预期。
• 不忽略失败定位：集成测试失败时优先检查日志中的 ApplicationContext 初始化过程 和 Bean 创建顺序，而非直接看业务断言——很多问题源于依赖注入失败或 profile 加载错误。
真正做好多模块联合验证，核心是让测试环境尽可能贴近运行态，同时保持可控与可重入。它不替代单元测试，而是补全其无法覆盖的接口、配置、生命周期和协作逻辑。
