多模块项目中为集成测试单独建模块是否符合最佳实践？

项目模块与依赖关系 #

我的项目包含以下模块：

• core-module - 项目核心模块
• communication-api - 提供通信服务API的接口模块
• communication-msg-impl - communication-api的具体实现模块（为多种实现之一）

模块间依赖规则：

• core-module 仅在基础层面依赖communication-api，实际使用该模块时，需由用户自行引入communication-api的某个具体实现模块
• communication-msg-impl 依赖communication-api

需求与疑问 #

我需要验证core-module与communication-msg-impl配合的完整流程，但如果将这类测试放在core-module中，就必须为core-module添加communication-msg-impl的依赖，这违背了原有的模块设计初衷。

我有两个疑问：

1. 为这类跨模块集成测试单独创建独立模块是否属于最佳实践？
2. 如果后续有多个communication-api的实现模块，是否需要为每个实现都单独创建对应的测试模块？

回答 #

为这类跨模块的集成测试单独创建独立模块绝对是最佳实践，核心原因如下：

• 维持模块职责与解耦性：core-module的核心职责是提供基础核心功能，绑定具体实现依赖会破坏其设计初衷。独立的测试模块能保证原模块的依赖结构不受影响，维持模块间的解耦。
• 测试逻辑更聚焦：每个集成测试模块可以专注于验证core-module与某一个具体实现的协作流程，测试场景清晰，便于维护和排查问题。

针对多个实现模块的情况，确实需要为每个实现单独创建对应的集成测试模块。比如：

• 针对communication-msg-impl，创建core-msg-integration-test模块
• 针对另一个实现communication-email-impl，创建core-email-integration-test模块

这种模式的优势很明显：

• 每个测试模块仅引入必要依赖（core-module + 对应实现模块 + 测试框架），无冗余依赖
• 不同实现的集成测试可以独立运行，便于定位特定实现的问题
• 新增实现时只需添加对应的测试模块，不会对现有模块结构造成影响

另外，还可以考虑创建一个通用的集成测试基础模块，封装通用测试逻辑，让各个具体实现的测试模块依赖这个基础模块，减少重复代码的编写。

内容的提问来源于stack exchange，提问作者Johnyb