Quarkus多模块Maven项目集成测试：重复引入quarkus-maven-plugin的问题

场景背景 #

我正将现有Quarkus应用拆分为多模块：

• 3个应用模块A、B、C：各自负责一组控制器/API端点
• shared模块：存放共享代码与数据库访问逻辑
• deployment模块：负责打包所有模块，作为唯一可运行的Quarkus应用，生产环境可灵活组合不同版本的A、B、C（例如仅部署B的最新变更，暂不更新A）

针对集成测试的两种方案，有以下疑问及分析：

方案一：在应用模块内放置集成测试并引入quarkus-maven-plugin #

这种做法没有本质性的不良影响，但会带来几个细节问题：

• 模块职责不够纯粹：应用模块原本仅负责业务端点实现，现在额外承担测试依赖与插件配置，轻微偏离单一职责原则
• 存在构建冗余：每个应用模块引入插件后，执行mvn test时会触发Quarkus测试生命周期，但这些模块本身并非可运行的Quarkus应用，会产生少量不必要的插件初始化开销（中小型项目可忽略）
• 依赖管理复杂度提升：每个应用模块需维护Quarkus测试相关依赖与插件版本，虽可通过父pom统一管理，但仍多了一层配置

不过该方案的优势也很直接：测试代码与业务代码同模块存放，修改端点后可直接同步调整测试，开发效率更高。

方案二：拆分独立的A-tests、B-tests、C-tests测试模块 #

这个方案更符合模块化设计的最佳实践，核心优势如下：

• 职责边界清晰：应用模块专注业务实现，测试模块专注集成测试，完全遵循单一职责
• 简化应用模块配置：只有测试模块需要引入quarkus-maven-plugin，应用模块的pom仅需维护业务相关依赖，保持简洁
• 测试执行更灵活：可单独运行某个测试模块的用例，无需构建整个应用模块，大型项目中能有效节省构建时间
• 版本控制更可控：测试模块可独立于应用模块调整版本（通常保持同步），也能更灵活适配不同版本的Quarkus测试工具

唯一的小缺点是项目结构会新增几个测试模块，初期搭建时需多做一些pom配置，但长期来看维护成本更低。

总结建议 #

如果项目规模较小、追求开发便捷性，方案一完全可以接受；如果项目规模较大，或对模块化规范要求较高，方案二更值得采用——它能让模块边界更清晰，后续维护与扩展更顺畅。

内容的提问来源于stack exchange，提问作者Werner de Groot