1. 为什么你的Maven项目需要JUnit依赖如果你正在用Java写代码尤其是用Maven管理项目那么JUnit几乎是你绕不开的一个名字。它不是什么高深莫测的黑科技而是你日常开发中用来验证“我写的这段代码到底对不对”的最基础、最趁手的工具。想象一下你写了一个计算器程序里面有个add方法你当然可以手动写个main方法打印出add(1, 2)的结果然后自己用眼睛看是不是等于3。但当你有一百个、一千个这样的方法每次修改代码后都手动测一遍这效率低得可怕而且极易出错。JUnit就是帮你自动化这个“看结果”过程的工具它让你能写一段代码来测试另一段代码一键运行所有测试并清晰地告诉你哪些通过了绿色哪些失败了红色。在Maven项目中JUnit依赖的配置看似简单就是往pom.xml文件里加几行XML。但为什么我强调“亲测有效”因为在实际操作中新手甚至一些有经验的开发者都可能因为版本冲突、作用域scope设置不当、或者依赖声明不完整导致测试无法运行、IDE报错、或者构建过程出问题。这篇文章的目的就是不仅告诉你“怎么加”更要拆解清楚“为什么这么加”以及在不同场景下比如用JUnit 4还是JUnit 5该如何选择并分享一些我踩过坑之后总结出来的配置技巧确保你一次配置成功后续无忧。2. JUnit版本选择JUnit 4 vs. JUnit 5的深度抉择在添加依赖之前第一个要做的决定就是选择JUnit的版本。目前主流有两个大版本JUnit 4和JUnit 5。它们不是简单的升级关系在架构和用法上有显著区别选错了后面会很麻烦。JUnit 4经典但渐入暮年JUnit 4发布于2006年是过去十多年Java单元测试的事实标准。它的核心就是一个junit.jar。如果你看到测试类上有Test注解并且导入的包是org.junit.Test那基本就是JUnit 4。它的优点是极其普及几乎所有老项目、旧教程都基于它生态成熟。但它的缺点也很明显架构单一扩展性差注解功能有限与Java 8的一些新特性如Lambda、Stream结合不够优雅。JUnit 5现代测试框架的集大成者JUnit 5在2017年发布它被设计成一个模块化的平台主要由三个子模块组成JUnit Jupiter这是编写新测试的核心编程模型和扩展模型。我们常用的Test、BeforeEach等注解都来自这里包名是org.junit.jupiter.api。JUnit Vintage这是一个兼容层用于在JUnit 5平台上运行JUnit 3或JUnit 4的测试。如果你的项目是老项目想逐步迁移到JUnit 5就需要它。JUnit Platform这是在JVM上启动测试框架的基础不仅服务于JUnit也支持其他测试框架如TestNG。IDE和构建工具Maven、Gradle通过它与测试框架交互。如何选择新项目无历史包袱强烈推荐直接使用JUnit 5。它更现代功能更强大与Java 8配合更好是未来的方向。老项目大量现存JUnit 4测试如果短期内不打算重写所有测试可以继续使用JUnit 4。但如果想引入JUnit 5的新特性可以混合使用通过添加JUnit Vintage模块来运行旧的JUnit 4测试同时新写的测试用JUnit Jupiter。这需要一个稍复杂的依赖配置。依赖的第三方库或公司框架强制要求有些旧的框架或工具可能对JUnit 4有强依赖这时候可能需要妥协。但在2023年及以后这种情况越来越少了。注意JUnit 5和JUnit 4的注解和API大部分不兼容。你不能在一个测试类里混用org.junit.Test和org.junit.jupiter.api.Test。Maven Surefire插件负责运行测试需要相应的配置才能正确识别和运行不同版本的测试。基于以上分析除非有强制的历史原因否则我们的配置将以JUnit 5作为标准。下面会给出针对纯JUnit 5、以及混合JUnit 4/5场景的两种“亲测有效”配置方案。3. 纯JUnit 5依赖配置详解与实操对于全新的项目我们追求最简洁、最现代的配置。JUnit 5官方推荐使用一个名为junit-jupiter的聚合依赖BOM它帮你管理好了所有子模块的版本避免版本不匹配的问题。3.1 基础依赖配置打开你的Maven项目根目录下的pom.xml文件找到dependencies部分添加如下内容dependencies !-- 其他项目依赖... -- !-- JUnit 5 Jupiter API Engine -- dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.0/version !-- 请使用当前最新稳定版 -- scopetest/scope /dependency /dependencies逐行解析与避坑指南groupId和artifactIdorg.junit.jupiter和junit-jupiter是JUnit 5核心的坐标。这个junit-jupiter依赖是一个“聚合依赖”Bill of Materials, BOM的一种简化使用它本身不包含代码但会传递性引入三个核心子模块junit-jupiter-api编写测试用的API注解如Test,BeforeEach。junit-jupiter-params参数化测试支持。junit-jupiter-engine测试引擎在运行时发现和执行测试。 你不需要单独声明它们这一个依赖就够了非常省心。version这里我写了5.10.0这是截至我知识截止日期2023年10月的一个较新稳定版。强烈建议你访问 Maven中央仓库 查看最新版本并替换。使用过旧的版本可能会缺少一些新特性或修复。scopetest/scope这是至关重要的一步。scope设置为test意味着这个依赖只在编译和运行测试代码时有效不会被打包到最终的生产环境JAR/WAR文件中。这符合“测试工具”的定位能避免无谓地增大发布包体积也是Maven最佳实践。3.2 配置Maven Surefire插件以支持JUnit 5仅仅添加依赖还不够。Maven默认使用maven-surefire-plugin来运行单元测试而它的旧版本可能无法自动识别JUnit 5的测试引擎。因此我们需要在pom.xml的build部分显式配置该插件。在pom.xml的project根标签下找到或创建build-plugins部分添加如下配置build plugins !-- 其他插件... -- !-- 配置Maven Surefire Plugin以支持JUnit 5 -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version !-- 建议使用较新版本对JUnit 5支持更好 -- /plugin /plugins /build为什么需要这个配置在Surefire Plugin 2.22.0及以上版本它已经内置了对JUnit 5 Platform的支持能够自动发现并运行JUnit JupiterJUnit 5和JUnit VintageJUnit 4兼容的测试。我们指定一个较新的版本如3.2.5就是为了确保这个自动发现机制生效。如果你不配置而你的Maven版本自带的Surefire插件很旧比如2.19那么当你运行mvn test时可能会一个测试都找不到。3.3 验证配置是否生效配置完成后我们来写一个最简单的测试验证一下。创建测试类在Maven标准目录src/test/java下如果没有请创建新建一个包如com.example.demo然后创建一个Java类例如CalculatorTest.java。编写测试代码package com.example.demo; import org.junit.jupiter.api.Test; // 注意是jupiter.api import static org.junit.jupiter.api.Assertions.assertEquals; public class CalculatorTest { Test void testAddition() { Calculator calculator new Calculator(); int result calculator.add(2, 3); assertEquals(5, result, 2 3 should equal 5); } }注意这里的Calculator是你假设的被测类需要你在src/main/java下有一个对应的类或者你可以先写一个简单的实现。运行测试在IDE中右键点击测试类或方法选择“Run as JUnit Test”。IntelliJ IDEA和Eclipse都对JUnit 5有很好的支持应该能直接识别并运行看到绿色的成功条。使用Maven命令在项目根目录打开终端执行mvn clean test。Maven会编译项目并运行所有测试。在控制台输出中你应该能看到类似[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0的成功信息。如果以上步骤都成功了恭喜你纯JUnit 5环境配置成功4. 混合环境在JUnit 5项目中运行遗留的JUnit 4测试现实情况往往是我们需要接手或维护一个老项目里面已经有成百上千个用JUnit 4编写的测试用例。全部重写为JUnit 5成本太高风险也大。这时我们就需要搭建一个混合环境让JUnit 5平台既能运行新的JUnit Jupiter测试也能运行旧的JUnit 4测试。4.1 依赖配置调整我们需要在依赖中额外添加junit-vintage-engine并确保有JUnit 4的依赖。dependencies !-- 其他项目依赖... -- !-- 1. JUnit 5 (Jupiter) 用于新测试 -- dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.0/version scopetest/scope /dependency !-- 2. JUnit Vintage Engine (用于运行JUnit 4测试) -- dependency groupIdorg.junit.vintage/groupId artifactIdjunit-vintage-engine/artifactId version5.10.0/version !-- 版本号最好与junit-jupiter保持一致 -- scopetest/scope /dependency !-- 3. JUnit 4 (旧测试本身依赖它) -- dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.13.2/version !-- 使用较新的4.13.x避免已知bug -- scopetest/scope /dependency /dependencies配置解析junit-vintage-engine这是JUnit 5提供的“老式发动机”它知道如何把JUnit 4的测试“翻译”成JUnit Platform能理解的形式从而在同一个测试运行周期内执行。junit:junit这是JUnit 4本身的库。你的旧测试类使用org.junit.Test在编译和运行时需要它。版本一致性junit-jupiter和junit-vintage-engine的版本号强烈建议保持一致如都是5.10.0因为它们同属JUnit 5项目内部协作更紧密。4.2 Surefire插件配置同样重要混合环境下Surefire插件的配置与纯JUnit 5环境一样建议使用较新版本2.22.0以确保自动发现所有测试引擎。build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version /plugin /plugins /build4.3 混合环境下的注意事项与常见问题类路径冲突理论上JUnit 4和JUnit 5的类是不同的包名不同所以不会有直接的类冲突。但要注意一些第三方库如Hamcrest的版本兼容性。测试发现配置正确后运行mvn testSurefire插件会同时激活JUnit Jupiter引擎和JUnit Vintage引擎。你会在日志中看到它们都被加载然后所有测试无论新旧都会被找到并执行。一个典型的坑RunWith注解JUnit 4中常用的RunWith(SpringRunner.class)或RunWith(MockitoJUnitRunner.class)等在JUnit 5中有了新的替代品如ExtendWith。在混合环境中旧的JUnit 4测试可以继续使用RunWith新的JUnit 5测试则应使用ExtendWith。不要试图在同一个测试类里混用两种风格的注解。如何逐步迁移混合环境是迁移的过渡状态。你可以制定计划每次修改某个模块时将其中的JUnit 4测试逐步重写为JUnit 5测试。当某个模块的所有测试都升级后可以从该模块的pom.xml中移除junit-vintage-engine和junit:junit依赖。最终目标是完全移除它们。5. 进阶配置与最佳实践完成了基本依赖配置你的测试就能跑了。但要构建一个健壮、高效的测试体系还需要了解一些进阶配置和最佳实践。5.1 使用JUnit BOM管理版本对于大型项目或多模块项目手动管理每个模块的JUnit版本很容易出错。JUnit提供了Bill of Materials (BOM)可以统一管理所有JUnit相关组件的版本。在你的父POM或项目POM的dependencyManagement部分引入BOMdependencyManagement dependencies dependency groupIdorg.junit/groupId artifactIdjunit-bom/artifactId version5.10.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement引入BOM后在dependencies里声明JUnit依赖时就可以省略version标签了版本会自动由BOM统一管理。dependencies dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId !-- 版本由BOM管理 -- scopetest/scope /dependency /dependencies这样做的好处是当你需要升级JUnit版本时只需要修改BOM中的那一处版本号即可所有子模块都会同步更新极大减少了维护成本。5.2 测试依赖的作用域Scope深入理解我们之前一直用scopetest/scope。Maven主要有以下几种作用域compile默认值。对主代码和测试代码都有效会打包。test仅对测试代码有效不打包。JUnit、Mockito、TestContainers等纯测试工具必须用此作用域。provided编译和测试时有效但运行时由容器如Servlet容器提供不打包。比如servlet-api。runtime编译时不需要运行时需要会打包。比如数据库驱动。一个常见的错误是把junit的scope设成了compile这虽然不会导致编译错误但会让你的生产代码包毫无必要地包含测试框架违反了依赖清晰的原则。5.3 配置Surefire插件以跳过测试或包含/排除特定测试在开发过程中有时你可能想跳过耗时的测试或者只运行某个模块的测试。跳过所有测试mvn clean install -DskipTests跳过测试编译和执行mvn clean install -Dmaven.test.skiptrue在POM中永久配置跳过不推荐仅用于特殊场景plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version configuration skipTeststrue/skipTests /configuration /plugin只运行匹配特定模式的测试类可以通过includes配置。plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version configuration includes include**/*IT.java/include !-- 只运行以IT结尾的集成测试 -- include**/Test*.java/include /includes excludes exclude**/*SlowTest.java/exclude !-- 排除慢速测试 -- /excludes /configuration /plugin5.4 集成其他测试工具现代Java测试很少只用JUnit。通常会结合Mockito模拟对象、AssertJ流式断言、Testcontainers集成测试等。它们的依赖同样需要正确添加到pom.xml中并且scope通常也是test。一个常见的测试栈依赖配置示例dependencies !-- JUnit 5 -- dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.0/version scopetest/scope /dependency !-- Mockito for mocking -- dependency groupIdorg.mockito/groupId artifactIdmockito-core/artifactId version5.7.0/version scopetest/scope /dependency !-- Mockito extension for JUnit 5 -- dependency groupIdorg.mockito/groupId artifactIdmockito-junit-jupiter/artifactId version5.7.0/version scopetest/scope /dependency !-- AssertJ for fluent assertions -- dependency groupIdorg.assertj/groupId artifactIdassertj-core/artifactId version3.24.2/version scopetest/scope /dependency /dependencies注意mockito-junit-jupiter是为了让Mockito更好地与JUnit 5的扩展模型ExtendWith协同工作。6. 疑难排查当“亲测有效”变成“亲测无效”时即使按照指南操作有时环境差异、IDE缓存、Maven仓库问题也可能导致配置不生效。这里提供一套排查流程。6.1 症状Maven命令mvn test找不到测试检查1测试类位置和命名。确保测试类在src/test/java目录下且类名以Test开头或结尾这是Surefire的默认模式或者你使用了Test注解。检查2Surefire插件版本。确认pom.xml中配置的surefire-plugin版本是2.22.0或更高。可以临时在命令行用mvn surefire:test直接运行插件看更详细的日志。检查3依赖是否下载成功。检查本地Maven仓库~/.m2/repository中是否存在org/junit/jupiter等目录。可以尝试删除相关目录后运行mvn clean compile -U强制更新依赖。检查4控制台日志。运行mvn test -X调试模式或mvn test -e显示错误详情查看是否有关于“No tests to run”的警告或错误以及Surefire插件加载了哪些测试引擎。6.2 症状IDE如IntelliJ IDEA无法识别Test注解或不能运行测试检查1IDE的Maven项目导入。在IDEA中右键点击项目 -Maven-Reload Project。这会让IDE重新从pom.xml同步依赖和配置。检查2模块的依赖范围。在IDEA的Project Structure(CtrlShiftAltS)中查看对应模块的Dependencies确认JUnit依赖的Scope是Test并且已被正确识别。检查3编译器输出路径。确保File-Project Structure-Project Settings-Modules-Paths中Test output path指向正确的目录通常是target/test-classes。6.3 症状测试运行时出现NoClassDefFoundError或NoSuchMethodError这通常是版本冲突或依赖传递导致的。检查1使用Maven依赖树。在项目根目录运行mvn dependency:tree -Dincludes*junit*。这会打印出所有与JUnit相关的依赖包括传递性依赖。查看是否有多个不同版本的JUnit 4或JUnit 5被引入。如果有需要使用exclusions排除掉不需要的传递依赖。检查2统一版本。确保所有JUnit 5相关组件junit-jupiter, junit-vintage-engine, junit-platform-*的版本一致。使用BOM是解决此问题的最佳实践。6.4 一个真实案例Spring Boot项目中的JUnit 5配置Spring Boot从2.2.x版本开始其spring-boot-starter-test默认就包含了JUnit 5Jupiter的依赖并且排除了JUnit 4Vintage。所以对于新的Spring Boot项目你通常不需要手动添加JUnit依赖。但如果你需要运行遗留的JUnit 4测试就需要显式地添加junit-vintage-engine依赖并且Spring Boot可能会因为它的依赖管理而覆盖你的版本。这时最好在dependencyManagement中优先导入JUnit的BOM或者在你的依赖声明中明确指定版本。配置JUnit依赖这个看似简单的动作背后是构建可靠Java项目测试基石的开始。从版本选择、依赖声明、插件配置到疑难排查每一步都蕴含着对项目结构和构建工具的理解。我个人的体会是在项目初期就确立清晰、一致的测试依赖策略比如强制使用JUnit 5BOM能避免后续大量的维护混乱。对于混合环境明确其作为过渡状态的定位并制定清晰的迁移路径比让它长期存在更重要。最后别忘了定期更新依赖版本享受新版本带来的性能提升和新特性但务必在非关键分支上做好充分的回归测试。
Maven项目JUnit依赖配置全解析：从版本选择到实战避坑
发布时间：2026/7/29 5:29:32
1. 为什么你的Maven项目需要JUnit依赖如果你正在用Java写代码尤其是用Maven管理项目那么JUnit几乎是你绕不开的一个名字。它不是什么高深莫测的黑科技而是你日常开发中用来验证“我写的这段代码到底对不对”的最基础、最趁手的工具。想象一下你写了一个计算器程序里面有个add方法你当然可以手动写个main方法打印出add(1, 2)的结果然后自己用眼睛看是不是等于3。但当你有一百个、一千个这样的方法每次修改代码后都手动测一遍这效率低得可怕而且极易出错。JUnit就是帮你自动化这个“看结果”过程的工具它让你能写一段代码来测试另一段代码一键运行所有测试并清晰地告诉你哪些通过了绿色哪些失败了红色。在Maven项目中JUnit依赖的配置看似简单就是往pom.xml文件里加几行XML。但为什么我强调“亲测有效”因为在实际操作中新手甚至一些有经验的开发者都可能因为版本冲突、作用域scope设置不当、或者依赖声明不完整导致测试无法运行、IDE报错、或者构建过程出问题。这篇文章的目的就是不仅告诉你“怎么加”更要拆解清楚“为什么这么加”以及在不同场景下比如用JUnit 4还是JUnit 5该如何选择并分享一些我踩过坑之后总结出来的配置技巧确保你一次配置成功后续无忧。2. JUnit版本选择JUnit 4 vs. JUnit 5的深度抉择在添加依赖之前第一个要做的决定就是选择JUnit的版本。目前主流有两个大版本JUnit 4和JUnit 5。它们不是简单的升级关系在架构和用法上有显著区别选错了后面会很麻烦。JUnit 4经典但渐入暮年JUnit 4发布于2006年是过去十多年Java单元测试的事实标准。它的核心就是一个junit.jar。如果你看到测试类上有Test注解并且导入的包是org.junit.Test那基本就是JUnit 4。它的优点是极其普及几乎所有老项目、旧教程都基于它生态成熟。但它的缺点也很明显架构单一扩展性差注解功能有限与Java 8的一些新特性如Lambda、Stream结合不够优雅。JUnit 5现代测试框架的集大成者JUnit 5在2017年发布它被设计成一个模块化的平台主要由三个子模块组成JUnit Jupiter这是编写新测试的核心编程模型和扩展模型。我们常用的Test、BeforeEach等注解都来自这里包名是org.junit.jupiter.api。JUnit Vintage这是一个兼容层用于在JUnit 5平台上运行JUnit 3或JUnit 4的测试。如果你的项目是老项目想逐步迁移到JUnit 5就需要它。JUnit Platform这是在JVM上启动测试框架的基础不仅服务于JUnit也支持其他测试框架如TestNG。IDE和构建工具Maven、Gradle通过它与测试框架交互。如何选择新项目无历史包袱强烈推荐直接使用JUnit 5。它更现代功能更强大与Java 8配合更好是未来的方向。老项目大量现存JUnit 4测试如果短期内不打算重写所有测试可以继续使用JUnit 4。但如果想引入JUnit 5的新特性可以混合使用通过添加JUnit Vintage模块来运行旧的JUnit 4测试同时新写的测试用JUnit Jupiter。这需要一个稍复杂的依赖配置。依赖的第三方库或公司框架强制要求有些旧的框架或工具可能对JUnit 4有强依赖这时候可能需要妥协。但在2023年及以后这种情况越来越少了。注意JUnit 5和JUnit 4的注解和API大部分不兼容。你不能在一个测试类里混用org.junit.Test和org.junit.jupiter.api.Test。Maven Surefire插件负责运行测试需要相应的配置才能正确识别和运行不同版本的测试。基于以上分析除非有强制的历史原因否则我们的配置将以JUnit 5作为标准。下面会给出针对纯JUnit 5、以及混合JUnit 4/5场景的两种“亲测有效”配置方案。3. 纯JUnit 5依赖配置详解与实操对于全新的项目我们追求最简洁、最现代的配置。JUnit 5官方推荐使用一个名为junit-jupiter的聚合依赖BOM它帮你管理好了所有子模块的版本避免版本不匹配的问题。3.1 基础依赖配置打开你的Maven项目根目录下的pom.xml文件找到dependencies部分添加如下内容dependencies !-- 其他项目依赖... -- !-- JUnit 5 Jupiter API Engine -- dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.0/version !-- 请使用当前最新稳定版 -- scopetest/scope /dependency /dependencies逐行解析与避坑指南groupId和artifactIdorg.junit.jupiter和junit-jupiter是JUnit 5核心的坐标。这个junit-jupiter依赖是一个“聚合依赖”Bill of Materials, BOM的一种简化使用它本身不包含代码但会传递性引入三个核心子模块junit-jupiter-api编写测试用的API注解如Test,BeforeEach。junit-jupiter-params参数化测试支持。junit-jupiter-engine测试引擎在运行时发现和执行测试。 你不需要单独声明它们这一个依赖就够了非常省心。version这里我写了5.10.0这是截至我知识截止日期2023年10月的一个较新稳定版。强烈建议你访问 Maven中央仓库 查看最新版本并替换。使用过旧的版本可能会缺少一些新特性或修复。scopetest/scope这是至关重要的一步。scope设置为test意味着这个依赖只在编译和运行测试代码时有效不会被打包到最终的生产环境JAR/WAR文件中。这符合“测试工具”的定位能避免无谓地增大发布包体积也是Maven最佳实践。3.2 配置Maven Surefire插件以支持JUnit 5仅仅添加依赖还不够。Maven默认使用maven-surefire-plugin来运行单元测试而它的旧版本可能无法自动识别JUnit 5的测试引擎。因此我们需要在pom.xml的build部分显式配置该插件。在pom.xml的project根标签下找到或创建build-plugins部分添加如下配置build plugins !-- 其他插件... -- !-- 配置Maven Surefire Plugin以支持JUnit 5 -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version !-- 建议使用较新版本对JUnit 5支持更好 -- /plugin /plugins /build为什么需要这个配置在Surefire Plugin 2.22.0及以上版本它已经内置了对JUnit 5 Platform的支持能够自动发现并运行JUnit JupiterJUnit 5和JUnit VintageJUnit 4兼容的测试。我们指定一个较新的版本如3.2.5就是为了确保这个自动发现机制生效。如果你不配置而你的Maven版本自带的Surefire插件很旧比如2.19那么当你运行mvn test时可能会一个测试都找不到。3.3 验证配置是否生效配置完成后我们来写一个最简单的测试验证一下。创建测试类在Maven标准目录src/test/java下如果没有请创建新建一个包如com.example.demo然后创建一个Java类例如CalculatorTest.java。编写测试代码package com.example.demo; import org.junit.jupiter.api.Test; // 注意是jupiter.api import static org.junit.jupiter.api.Assertions.assertEquals; public class CalculatorTest { Test void testAddition() { Calculator calculator new Calculator(); int result calculator.add(2, 3); assertEquals(5, result, 2 3 should equal 5); } }注意这里的Calculator是你假设的被测类需要你在src/main/java下有一个对应的类或者你可以先写一个简单的实现。运行测试在IDE中右键点击测试类或方法选择“Run as JUnit Test”。IntelliJ IDEA和Eclipse都对JUnit 5有很好的支持应该能直接识别并运行看到绿色的成功条。使用Maven命令在项目根目录打开终端执行mvn clean test。Maven会编译项目并运行所有测试。在控制台输出中你应该能看到类似[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0的成功信息。如果以上步骤都成功了恭喜你纯JUnit 5环境配置成功4. 混合环境在JUnit 5项目中运行遗留的JUnit 4测试现实情况往往是我们需要接手或维护一个老项目里面已经有成百上千个用JUnit 4编写的测试用例。全部重写为JUnit 5成本太高风险也大。这时我们就需要搭建一个混合环境让JUnit 5平台既能运行新的JUnit Jupiter测试也能运行旧的JUnit 4测试。4.1 依赖配置调整我们需要在依赖中额外添加junit-vintage-engine并确保有JUnit 4的依赖。dependencies !-- 其他项目依赖... -- !-- 1. JUnit 5 (Jupiter) 用于新测试 -- dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.0/version scopetest/scope /dependency !-- 2. JUnit Vintage Engine (用于运行JUnit 4测试) -- dependency groupIdorg.junit.vintage/groupId artifactIdjunit-vintage-engine/artifactId version5.10.0/version !-- 版本号最好与junit-jupiter保持一致 -- scopetest/scope /dependency !-- 3. JUnit 4 (旧测试本身依赖它) -- dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.13.2/version !-- 使用较新的4.13.x避免已知bug -- scopetest/scope /dependency /dependencies配置解析junit-vintage-engine这是JUnit 5提供的“老式发动机”它知道如何把JUnit 4的测试“翻译”成JUnit Platform能理解的形式从而在同一个测试运行周期内执行。junit:junit这是JUnit 4本身的库。你的旧测试类使用org.junit.Test在编译和运行时需要它。版本一致性junit-jupiter和junit-vintage-engine的版本号强烈建议保持一致如都是5.10.0因为它们同属JUnit 5项目内部协作更紧密。4.2 Surefire插件配置同样重要混合环境下Surefire插件的配置与纯JUnit 5环境一样建议使用较新版本2.22.0以确保自动发现所有测试引擎。build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version /plugin /plugins /build4.3 混合环境下的注意事项与常见问题类路径冲突理论上JUnit 4和JUnit 5的类是不同的包名不同所以不会有直接的类冲突。但要注意一些第三方库如Hamcrest的版本兼容性。测试发现配置正确后运行mvn testSurefire插件会同时激活JUnit Jupiter引擎和JUnit Vintage引擎。你会在日志中看到它们都被加载然后所有测试无论新旧都会被找到并执行。一个典型的坑RunWith注解JUnit 4中常用的RunWith(SpringRunner.class)或RunWith(MockitoJUnitRunner.class)等在JUnit 5中有了新的替代品如ExtendWith。在混合环境中旧的JUnit 4测试可以继续使用RunWith新的JUnit 5测试则应使用ExtendWith。不要试图在同一个测试类里混用两种风格的注解。如何逐步迁移混合环境是迁移的过渡状态。你可以制定计划每次修改某个模块时将其中的JUnit 4测试逐步重写为JUnit 5测试。当某个模块的所有测试都升级后可以从该模块的pom.xml中移除junit-vintage-engine和junit:junit依赖。最终目标是完全移除它们。5. 进阶配置与最佳实践完成了基本依赖配置你的测试就能跑了。但要构建一个健壮、高效的测试体系还需要了解一些进阶配置和最佳实践。5.1 使用JUnit BOM管理版本对于大型项目或多模块项目手动管理每个模块的JUnit版本很容易出错。JUnit提供了Bill of Materials (BOM)可以统一管理所有JUnit相关组件的版本。在你的父POM或项目POM的dependencyManagement部分引入BOMdependencyManagement dependencies dependency groupIdorg.junit/groupId artifactIdjunit-bom/artifactId version5.10.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement引入BOM后在dependencies里声明JUnit依赖时就可以省略version标签了版本会自动由BOM统一管理。dependencies dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId !-- 版本由BOM管理 -- scopetest/scope /dependency /dependencies这样做的好处是当你需要升级JUnit版本时只需要修改BOM中的那一处版本号即可所有子模块都会同步更新极大减少了维护成本。5.2 测试依赖的作用域Scope深入理解我们之前一直用scopetest/scope。Maven主要有以下几种作用域compile默认值。对主代码和测试代码都有效会打包。test仅对测试代码有效不打包。JUnit、Mockito、TestContainers等纯测试工具必须用此作用域。provided编译和测试时有效但运行时由容器如Servlet容器提供不打包。比如servlet-api。runtime编译时不需要运行时需要会打包。比如数据库驱动。一个常见的错误是把junit的scope设成了compile这虽然不会导致编译错误但会让你的生产代码包毫无必要地包含测试框架违反了依赖清晰的原则。5.3 配置Surefire插件以跳过测试或包含/排除特定测试在开发过程中有时你可能想跳过耗时的测试或者只运行某个模块的测试。跳过所有测试mvn clean install -DskipTests跳过测试编译和执行mvn clean install -Dmaven.test.skiptrue在POM中永久配置跳过不推荐仅用于特殊场景plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version configuration skipTeststrue/skipTests /configuration /plugin只运行匹配特定模式的测试类可以通过includes配置。plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version configuration includes include**/*IT.java/include !-- 只运行以IT结尾的集成测试 -- include**/Test*.java/include /includes excludes exclude**/*SlowTest.java/exclude !-- 排除慢速测试 -- /excludes /configuration /plugin5.4 集成其他测试工具现代Java测试很少只用JUnit。通常会结合Mockito模拟对象、AssertJ流式断言、Testcontainers集成测试等。它们的依赖同样需要正确添加到pom.xml中并且scope通常也是test。一个常见的测试栈依赖配置示例dependencies !-- JUnit 5 -- dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.0/version scopetest/scope /dependency !-- Mockito for mocking -- dependency groupIdorg.mockito/groupId artifactIdmockito-core/artifactId version5.7.0/version scopetest/scope /dependency !-- Mockito extension for JUnit 5 -- dependency groupIdorg.mockito/groupId artifactIdmockito-junit-jupiter/artifactId version5.7.0/version scopetest/scope /dependency !-- AssertJ for fluent assertions -- dependency groupIdorg.assertj/groupId artifactIdassertj-core/artifactId version3.24.2/version scopetest/scope /dependency /dependencies注意mockito-junit-jupiter是为了让Mockito更好地与JUnit 5的扩展模型ExtendWith协同工作。6. 疑难排查当“亲测有效”变成“亲测无效”时即使按照指南操作有时环境差异、IDE缓存、Maven仓库问题也可能导致配置不生效。这里提供一套排查流程。6.1 症状Maven命令mvn test找不到测试检查1测试类位置和命名。确保测试类在src/test/java目录下且类名以Test开头或结尾这是Surefire的默认模式或者你使用了Test注解。检查2Surefire插件版本。确认pom.xml中配置的surefire-plugin版本是2.22.0或更高。可以临时在命令行用mvn surefire:test直接运行插件看更详细的日志。检查3依赖是否下载成功。检查本地Maven仓库~/.m2/repository中是否存在org/junit/jupiter等目录。可以尝试删除相关目录后运行mvn clean compile -U强制更新依赖。检查4控制台日志。运行mvn test -X调试模式或mvn test -e显示错误详情查看是否有关于“No tests to run”的警告或错误以及Surefire插件加载了哪些测试引擎。6.2 症状IDE如IntelliJ IDEA无法识别Test注解或不能运行测试检查1IDE的Maven项目导入。在IDEA中右键点击项目 -Maven-Reload Project。这会让IDE重新从pom.xml同步依赖和配置。检查2模块的依赖范围。在IDEA的Project Structure(CtrlShiftAltS)中查看对应模块的Dependencies确认JUnit依赖的Scope是Test并且已被正确识别。检查3编译器输出路径。确保File-Project Structure-Project Settings-Modules-Paths中Test output path指向正确的目录通常是target/test-classes。6.3 症状测试运行时出现NoClassDefFoundError或NoSuchMethodError这通常是版本冲突或依赖传递导致的。检查1使用Maven依赖树。在项目根目录运行mvn dependency:tree -Dincludes*junit*。这会打印出所有与JUnit相关的依赖包括传递性依赖。查看是否有多个不同版本的JUnit 4或JUnit 5被引入。如果有需要使用exclusions排除掉不需要的传递依赖。检查2统一版本。确保所有JUnit 5相关组件junit-jupiter, junit-vintage-engine, junit-platform-*的版本一致。使用BOM是解决此问题的最佳实践。6.4 一个真实案例Spring Boot项目中的JUnit 5配置Spring Boot从2.2.x版本开始其spring-boot-starter-test默认就包含了JUnit 5Jupiter的依赖并且排除了JUnit 4Vintage。所以对于新的Spring Boot项目你通常不需要手动添加JUnit依赖。但如果你需要运行遗留的JUnit 4测试就需要显式地添加junit-vintage-engine依赖并且Spring Boot可能会因为它的依赖管理而覆盖你的版本。这时最好在dependencyManagement中优先导入JUnit的BOM或者在你的依赖声明中明确指定版本。配置JUnit依赖这个看似简单的动作背后是构建可靠Java项目测试基石的开始。从版本选择、依赖声明、插件配置到疑难排查每一步都蕴含着对项目结构和构建工具的理解。我个人的体会是在项目初期就确立清晰、一致的测试依赖策略比如强制使用JUnit 5BOM能避免后续大量的维护混乱。对于混合环境明确其作为过渡状态的定位并制定清晰的迁移路径比让它长期存在更重要。最后别忘了定期更新依赖版本享受新版本带来的性能提升和新特性但务必在非关键分支上做好充分的回归测试。
