Spring Boot Maven共享模块混存测试工具类方案选型咨询

核心结论 #

生产逻辑与测试工具混合存放在同一个shared模块完全不合理，必须拆分独立模块专门存放公共测试工具。

混合存放模式的明确问题 #

• 依赖污染不可逆：测试相关依赖（如junit-vintage-engine、spring-test、mockito等）无法设置为test作用域，会作为编译期依赖传递到所有下游业务模块，轻则导致生产构建产物体积虚高、测试依赖与业务自身依赖出现版本冲突，重则让测试组件出现在生产运行环境的classpath下，带来不必要的安全风险。
• 模块职责完全错位：shared模块的定位是承载生产环境可复用的公共逻辑（安全组件、DAO层Mapper、通用生产工具类等），测试工具仅在单元测试、集成测试阶段生效，两者的生命周期、使用场景、稳定性要求完全不同，混放违反单一职责原则，后续迭代很容易出现改测试工具误影响生产逻辑、升级生产依赖时误改测试组件版本的问题。
• 构建效率无意义损耗：所有依赖shared模块的业务模块在编译生产代码阶段，都要额外加载大量完全用不上的测试依赖，会拉长本地编译、CI流水线的执行时间，模块越多损耗越明显。

落地执行方案 #

• 新增独立的测试公共模块，推荐命名为common-test或者test-support，和现有业务模块保持统一的groupId，专门存放所有跨模块复用的测试相关代码：包括你提到的MockMvcTest抽象基类、通用Mock构造工具、测试用常量、自定义测试注解等。
• 模块结构与依赖配置规则：
  • common-test模块自身的公共测试工具类统一放在src/main/java目录下，模块自身的单元测试代码仍然放在src/test/java目录；
  • common-test模块内引入的JUnit、Spring Test、MockMvc等测试框架依赖，在当前模块pom中使用默认compile作用域即可，保证模块对外提供的测试工具能正常运行；
  • 所有下游业务模块（包括两个API模块、甚至shared模块自身如果需要用到测试工具）依赖common-test时，必须将依赖作用域设置为<scope>test</scope>，确保所有测试相关依赖仅在模块执行测试阶段生效，完全不会进入生产构建产物，也不会污染业务模块的编译期classpath。
• 清理原有shared模块：将所有测试相关类全部迁移到common-test模块，删除shared模块pom中所有测试相关依赖，仅保留安全逻辑、Mapper、生产通用工具类对应的生产依赖，保证shared模块的所有依赖都是生产运行必需的组件。

可选优化方向 #

如果后续公共测试工具积累到一定规模，可以按使用场景进一步细分子模块，比如拆分test-support-mvc专门承载MockMvc相关测试基类、test-support-db专门承载数据库测试相关封装（如测试容器配置、测试用数据源工具等），避免单个测试模块过于臃肿。
注意严格划清边界：生产环境需要用到的类一律不要放到common-test模块，比如和生产逻辑共用的枚举、DTO等组件仍然放在shared模块，common-test仅存放测试阶段独有的逻辑。

内容的提问来源于stack exchange，提问作者José Puente Fuentes