写测试这事儿我一直觉得是Java开发里最容易被低估的一环。很多新手拿到IDEA建好Spring Boot项目写了一个类然后想跑一下方法本身有没有问题第一反应是写main方法打印或者干脆postman一把梭。但真正的工程习惯是从IDEA里的Test注解开始的。这个注解背后是JUnit框架它让你不用启动整个应用就能验证一个方法的行为是否正确。今天我把在IDEA里用Test从环境配置到实战踩坑的完整经验整理出来新手可以直接照着抄老手也可以看看有没有你忽略的细节。1. 从零搭好测试环境IDEA里的JUnit依赖1.1 先搞清楚Test是哪来的很多人在IDEA里写了一个Test发现标红然后下意识认为是IDEA坏了。其实Test不是JDK自带的注解也不是IDEA的功能而是JUnit这个第三方测试框架提供的。你在代码里写的所有Test相当于告诉JUnit“这个方法是一个测试用例”JUnit的运行器会扫描这些方法逐个执行并统计结果。理解这一点很重要。如果项目里没有引入JUnit的依赖IDEA当然不知道Test是什么。所以第一步不是打开IDEA设置而是检查项目的依赖管理。1.2 在Maven/Gradle项目中添加JUnit依赖现在的Java项目十有八九是Maven或Gradle管理的。如果是Maven在pom.xml里加依赖。JUnit目前主流的两个大版本是JUnit 4和JUnit 5两者坐标完全不同!-- JUnit 4 -- dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.13.2/version scopetest/scope /dependency !-- JUnit 5 -- dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.2/version scopetest/scope /dependency注意JUnit 5的artifactId不是junit而是junit-jupiter这是一个聚合依赖包含了API、参数化测试和测试引擎。如果之前你用过junit-jupiter-api那是不够的因为IDEA和Maven运行测试时还需要junit-jupiter-engine。直接用junit-jupiter省心。Gradle项目则在build.gradle里加dependencies { testImplementation org.junit.jupiter:junit-jupiter:5.10.2 }如果是Spring Boot项目更省事。spring-boot-starter-test已经帮你打包好了JUnit 5、Mockito、AssertJ等常用测试库dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency这个依赖是Spring Boot 2.2之后默认使用JUnit 5之前是JUnit 4细节不同但基本用法一致。1.3 没有构建工具怎么加Jar包如果你没有用Maven/Gradle就是纯粹的IDEA项目那需要手动把JUnit的jar包加到工程里。简单做法是写Test后光标停在Test上按Alt EnterIDEA会弹出“Add JUnit to classpath”之类的快捷选项点一下它就会自动下载并引入。这是最不需要动脑的方法。但我建议尽早接触Maven或Gradle因为真实的团队项目不会用这种方式管理依赖。手动加jar包只适合临时写个小demo因为一旦依赖变多版本冲突就会成为灾难。2. 编写测试类的正确姿势注解、断言与命名2.1 Test的基本用法方法权限、返回类型、异常Test标记的方法需要满足约束不能是private不能有参数返回值最好声明为void。JUnit 4要求测试方法必须是public voidJUnit 5放宽了访问权限不用写public也能跑。如果一个方法有返回值JUnit会照常执行但不会去校验返回值所以通常没必要写返回类型。示例import org.junit.jupiter.api.Test; class DemoTest { Test void shouldReturnTrue() { // 这里是测试逻辑 } }还有一个常见的误区很多人以为测试方法名必须以test开头。JUnit 4时代确实有约定但加了Test注解后方法名可以随意。现在主流写法是直接用业务描述比如shouldReturnTrueWhenInputValid可读性更好。2.2 断言方法怎么选assertEquals、assertTrue、assertThrows等Test本身不包含任何判断逻辑真正判断“测试是否通过”的是断言。JUnit 4中静态导入org.junit.Assert.*JUnit 5中导入org.junit.jupiter.api.Assertions.*。常用的有这几个assertEquals(4, calculator.add(2, 2), 加法结果不对); assertTrue(list.isEmpty()); assertFalse(user.isActive()); assertNull(result); assertNotNull(result); assertThrows(IllegalArgumentException.class, () - { calculator.divide(1, 0); });JUnit 5的assertEquals还可以传第三个参数即失败时显示的消息这个对排错非常有用。assertThrows用于验证异常替代了JUnit 4里的Test(expected XxxException.class)推荐优先用assertThrows因为还能继续断言异常的信息。2.3 测试类命名与包结构约定测试类最好和被测试类放在同一个包下但放在src/test/java目录里。比如com.example.service.UserService测试类就是src/test/java/com/example/service/UserServiceTest。命名上一般是被测类名加Test后缀这是Maven Surefire默认扫描规则的一部分。为什么要放在相同包因为JUnit能看到包级私有成员。虽然我们一般不直接测私有方法但同包的设计本身更符合“测试与源码结构对齐”的原则。IDEA也能自动识别这种结构右键类名直接跳转到测试类。3. IDEA里运行Test的完整实操从单个方法到整个模块3.1 三种运行方式行号左侧运行、右键运行、快捷键运行写完测试类运行方式很简单。第一种在测试方法左侧的行号区域会出现一个绿色三角形图标点击它选择“Run 方法名()”就会执行当前这个单个测试方法。第二种在测试类的类名左侧或者右键点击类名选择“Run 类名”会运行这个类里的所有Test方法。第三种用快捷键。Windows/Linux下是Ctrl Shift F10macOS下是Control Shift R。这个快捷键的运行逻辑很智能光标在哪个测试方法上就运行哪个方法光标在类中但没有选中具体方法就会运行整个类。运行过一次之后可以直接按Shift F10macOS对应Control R重新运行上一次的测试配置。个人建议把首选项设为“Run tests using IntelliJ IDEA”而不是Gradle或Maven。位置在Settings - Build, Execution, Deployment - Build Tools - Gradle - Runner把“Run tests using”改成“IntelliJ IDEA”。因为直接用IDEA运行测试速度比起Gradle/Maven冷启动快很多而且结果展示更直观。但注意改成IDEA运行后某些只在Gradle/Maven里配置的测试环境变量可能不生效比如依赖Gradle过滤的资源文件这时候要回到构建工具运行。3.2 运行配置里的关键选项JUnit vs JUnit5大部分时候不需要手动创建运行配置IDEA会生成临时的JUnit配置。但如果你经常测试某个特定包或指定测试类可以打开Run - Edit Configurations点击左上角加号选择JUnit。这里有几个值得留意的配置项Test kind可以选择Class、Method、Package、Category等。Class / Method指定要运行的类和具体方法。VM options在这里可以加-Dfile.encodingUTF-8这类JVM参数。Working directory默认是项目根目录如果测试依赖文件路径需要确认这里是否正确。Use classpath of module选择对应的模块。如果是JUnit 5项目IDEA依然用“JUnit”配置类型不需要单独选“JUnit5”。IDEA会自动识别classpath中的JUnit平台并调起测试引擎。3.3 查看测试结果窗口进度条、统计、失败堆栈运行后底部会弹出“Run”工具窗口。绿色进度条表示全部通过红色表示存在失败。左边树状列表会列出所有测试方法点开某个失败的方法右侧是清晰的差异对比Expected和Actual的值如果断言时传了消息还会显示自定义的提示。真正的排错重点在“Failure”或者“Error”区分上。Failure是断言失败表示结果和预期不一致Error是测试执行过程中抛出了未捕获的异常一般是代码本身有问题。看堆栈信息时不要只看第一行往下翻到“Caused by”那里才有根本原因。3.4 条件跳过TestDisabled、EnabledIf等有时候测试还没写完或者依赖外部环境不想让它在CI里挂掉可以用Disabled跳过。JUnit 4里的注解是Ignore。Disabled(这里注释原因比如临时跳过等待接口联调完成) Test void notReadyTest() { // ... }JUnit 5还提供了更多条件注解比如EnabledOnOs(OS.WINDOWS)只让测试在Windows上跑EnabledIfEnvironmentVariable根据环境变量决定是否执行。日常开发中用得不多但CI中控制测试范围时很实用。4. 测试与构建工具集成Maven Surefire的坑4.1 mvn test 和IDEA运行Test的区别IDEA里的“运行”只是调起JUnit引擎并不会触发Maven的test生命周期。而mvn test会走完整的Maven流程编译、复制资源、运行Surefire插件再执行测试。两者最大的区别在于“环境”。如果你在pom.xml的build plugins里配置了插件比如maven-resources-plugin做资源替换或者maven-antrun-plugin生成文件那么只有mvn test才会触发这些过程。所以会出现一种情况IDEA里测试全绿mvn test却挂了。排查思路不是怀疑测试代码而是对比两边的运行环境最常见的差异是src/test/resources里的文件没有在IDEA中被正确复制到target/test-classes或者Maven配置的filter导致配置项不同。我的习惯是小步快速调试用IDEA提交代码前用mvn test全量跑一遍双保险。4.2 解决“There are test failures”导致install失败Maven在执行mvn install或mvn package时会触发测试一旦有测试失败默认会终止构建日志里会看到类似There are test failures并给出surefire报告的路径比如e:\source\usercenter\target\surefire-reports。看到这个别慌。先打开target/surefire-reports目录里面有.txt和.xml格式的测试报告比控制台输出更完整。优先看最近的失败测试类和方法名。如果你确认失败原因是环境问题比如测试需要连一个不存在的数据库而本地没有启动你可以选择跳过测试但如果是代码逻辑问题建议老实修复因为跳过测试只是把质量风险往后挪。4.3 跳过测试的正确姿势-DskipTests和-Dmaven.test.skiptrue经常有人问“IDEA在install的时候怎么跳过test”。其实关键参数有两个mvn install -DskipTests-DskipTests会跳过测试的执行但仍然会编译测试类。也就是说测试代码有语法错误时这个命令依然会失败。mvn install -Dmaven.test.skiptrue-Dmaven.test.skiptrue是更彻底的方式连测试代码的编译都跳过。这两个参数都有效但日常推荐-DskipTests因为它不会掩盖测试代码的编译问题。如果你嫌每次敲命令麻烦可以在IDEA的Maven工具窗口里找到“Toggle Skip Tests Mode”按钮点击后Maven会自动带上-DskipTests。或者打开Run - Edit Configurations在Maven运行配置的Command line里手动填参数。注意跳过测试只是临时手段。如果提交到CICI通常会单独跑测试任务这种参数不应该固化在pom.xml里否则等于废掉了自动化测试。5. 实战案例在Spring Boot项目里写一个带Test的接口测试5.1 引入spring-boot-starter-test并理解核心组件Spring Boot项目的测试不是单纯调一个方法而是要验证依赖注入、数据库连接、Controller路由等。spring-boot-starter-test包含了JUnit 5、Spring Test、AssertJ、Hamcrest、Mockito、JSONAssert等。这意味着你不必再手动添加JUnit依赖。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency添加后还需要标注SpringBootTest。这个注解会启动Spring上下文相当于在测试中把整个应用组装起来。代价是启动较慢所以如果只是想测一个Service方法可以不用SpringBootTest直接new出对象来测速度可能快很多。但涉及到Spring AOP、事务、自动配置时还是得靠它。5.2 写一个简单的Service单元测试假设有一个UserService里面有个方法判断用户是否为VIPService public class UserService { public boolean isVip(User user) { return user.getLevel() 3; } }对应的测试类可以这样写import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; class UserServiceTest { private final UserService userService new UserService(); Test void shouldReturnTrueWhenLevelGreaterThanOrEqualThree() { User vipUser new User(); vipUser.setLevel(3); assertTrue(userService.isVip(vipUser)); } Test void shouldReturnFalseWhenLevelLessThanThree() { User normalUser new User(); normalUser.setLevel(2); assertFalse(userService.isVip(normalUser)); } }这里不需要启动Spring因为UserService不依赖其他Bean。单元测试的重点是“只测当前类”外部依赖用Mock替代。5.3 写一个MockMvc的Web层测试再进一步测Controller。假设有UserControllerRestController RequestMapping(/users) public class UserController { GetMapping public ListUser list() { return List.of(new User(张三), new User(李四)); } }使用MockMvc可以在不真正启动Web服务器的情况下模拟HTTP请求import org.junit.jupiter.api.Test; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.test.web.servlet.MockMvc; import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get; import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*; SpringBootTest AutoConfigureMockMvc class UserControllerTest { Autowired private MockMvc mockMvc; Test void shouldReturnUserList() throws Exception { mockMvc.perform(get(/users)) .andExpect(status().isOk()) .andExpect(jsonPath($.length()).value(2)) .andExpect(jsonPath($[0].name).value(张三)); } }jsonPath是用来解析JSON响应体的表达式语言断言接口返回结构非常方便。这里建议用AutoConfigureMockMvc因为它只需要加载Web层相关的配置比启动完整上下文更快。如果项目里大量使用SpringBootTest导致测试很慢可以考虑切换到WebMvcTest只测Controller层再配合MockBean模拟Service。5.4 测试覆盖率怎么查看IDEA自带覆盖率工具不需要额外装插件。在测试类或其运行配置上右键选择“Run with Coverage”运行完IDEA会在编辑器左侧显示绿色和红色条绿色表示覆盖到的行红色表示没有覆盖到。打开覆盖率窗口还能看到类、方法、行覆盖率的百分比。覆盖率不用迷信100%。业务逻辑里容易出Bug的分支比如异常处理、边界条件优先覆盖。而getter/setter这种只有赋值和取值的代码覆盖率覆盖率低一点也无妨。IDEA的覆盖率工具还有一个“Add coverage to test suite”的功能能把多次运行的覆盖率合并在一起适合统计多个测试类整体覆盖情况。6. 常见问题与避坑经验我踩过的那些坑6.1 Test标红找不到符号这个问题反复出现原因是项目classpath里没有JUnit依赖。解决路径有两条如果是Maven项目检查pom.xml是否真的引入了依赖引入后记得刷新Maven让IDEA重新导入。如果是Gradle项目点一下Gradle工具窗口里的刷新按钮。还有一种情况是依赖已经存在但IDEA缓存坏了可以执行File - Invalidate Caches / Restart清缓存重启。注意如果你的项目用的JUnit 5但网上教程让你导入org.junit.Test那会标红因为JUnit 5的包名是org.junit.jupiter.api.Test。二者千万别混。6.2 运行时报No tests found这种提示常见于点击了测试类的运行按钮却输出“No tests found”或类似信息。可能原因有这几种测试方法加了privateJUnit无法调用。测试方法有参数但没配合ParameterizedTest。测试类不在src/test/java目录下Surefire默认不扫描。IDEA里可以看到测试类图标是不是绿色的小人如果不是说明IDEA不认为它是测试类。项目命名空间里存在JUnit 4和JUnit 5的引擎冲突可以尝试清理target目录后再跑。另外一个非常隐蔽的原因IDEA运行配置里选择了“All in package”但包路径下有多个模块的类运行器没有找到匹配测试。这种情况删掉旧的运行配置重新点击测试方法左侧的绿色箭头生成一次配置基本就能解决。6.3 测试方法执行顺序乱JUnit的默认执行顺序不固定这是设计如此为了测试之间不依赖顺序。如果你确实需要按顺序跑JUnit 4可以用FixMethodOrder(MethodSorters.NAME_ASCENDING)按照方法名字母序JUnit 5用组合注解TestMethodOrder(MethodOrderer.OrderAnnotation.class) class OrderTest { Test Order(1) void first() { } Test Order(2) void second() { } }但我要提醒一句测试之间不该依赖执行顺序。如果非要有先后说明你的测试有状态共享。正确做法是在BeforeEach里重建状态而不是把状态写在static字段里。6.4 控制台中文乱码导致断言失败测试中如果打印中文日志或断言中文内容IDEA控制台出现乱码比较常见。这其实不是Test的问题而是JVM默认编码和IDEA控制台编码不一致。解决办法打开Help - Edit Custom VM Options如果提示没有文件就创建一个加上-Dfile.encodingUTF-8重启IDEA。在Run - Edit Configurations里给当前的测试配置加VM options-Dfile.encodingUTF-8。如果用的是Maven运行确认MAVEN_OPTS或者pom.xml的project.build.sourceEncoding设置为UTF-8。遇到中文断言失败时先别急着改业务代码很可能只是编码问题导致期望的“用户”和实际输出的“锟斤拷”不同。6.5 测试跑太久或者IDEA卡死如果一个测试类里有大量SpringBootTest每个测试都启动一次Spring容器IDEA和机器会非常吃力。解决思路是把SpringBootTest尽量放在一个抽象的基类上让多个测试类继承同一个上下文SpringContext是缓存的多个测试类共用同一个上下文会快很多。如果单个测试方法里用了Thread.sleep等待异步结果这是坏味道容易造成测试不稳定。尽量用awaitility这类库轮询等待设置超时否则一旦环境波动测试就会误报。还有一点测试方法里创建的临时文件、数据库连接、线程池记得在AfterEach或AfterAll里清理。否则跑一个模块后临时文件堆积或者连接池线程不释放轻则IDEA变慢重则下一次测试失败。6.6 关于跳过测试的几个理解误区最后再说一下跳过测试。我在实际项目开发里见过有人把“测试失败就跳过”当成默认操作这是很危险的。跳过测试会导致代码质量问题被隐藏尤其是CI流水线上一旦跳过条件写死在配置里后续的提交都不会再执行测试。正确的处理方式先看失败原因。如果是测试代码写得不对修测试如果是业务代码Bug修业务代码只有确认是环境导致比如依赖的外部服务没启动才在本地临时加-DskipTests并且提交代码前必须用完整测试回归。我个人在实际操作中还有个习惯Test方法里的断言一定要带上自定义消息。比如assertEquals(用户列表大小不对, 3, list.size())。这样测试失败时看IDEA的报告就能立刻知道是哪一步逻辑出了问题而不需要一行行debug。不要小看这个细节它能省下你排查测试失败的大量时间。另外如果你还在用JUnit 4建议尽早升级到JUnit 5。JUnit 5的assertThrows、assertTimeout、参数化测试都比JUnit 4顺手得多而且它不是新东西了绝大多数项目都已经切换过来了。从今天开始每次写测试类先问自己一句这个测试要锁定的行为是什么想清楚再写断言测试才能真正成为你代码里的安全网。
从IDEA到Maven：Java单元测试的@Test注解全攻略与Spring Boot实践
写测试这事儿我一直觉得是Java开发里最容易被低估的一环。很多新手拿到IDEA建好Spring Boot项目写了一个类然后想跑一下方法本身有没有问题第一反应是写main方法打印或者干脆postman一把梭。但真正的工程习惯是从IDEA里的Test注解开始的。这个注解背后是JUnit框架它让你不用启动整个应用就能验证一个方法的行为是否正确。今天我把在IDEA里用Test从环境配置到实战踩坑的完整经验整理出来新手可以直接照着抄老手也可以看看有没有你忽略的细节。1. 从零搭好测试环境IDEA里的JUnit依赖1.1 先搞清楚Test是哪来的很多人在IDEA里写了一个Test发现标红然后下意识认为是IDEA坏了。其实Test不是JDK自带的注解也不是IDEA的功能而是JUnit这个第三方测试框架提供的。你在代码里写的所有Test相当于告诉JUnit“这个方法是一个测试用例”JUnit的运行器会扫描这些方法逐个执行并统计结果。理解这一点很重要。如果项目里没有引入JUnit的依赖IDEA当然不知道Test是什么。所以第一步不是打开IDEA设置而是检查项目的依赖管理。1.2 在Maven/Gradle项目中添加JUnit依赖现在的Java项目十有八九是Maven或Gradle管理的。如果是Maven在pom.xml里加依赖。JUnit目前主流的两个大版本是JUnit 4和JUnit 5两者坐标完全不同!-- JUnit 4 -- dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.13.2/version scopetest/scope /dependency !-- JUnit 5 -- dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.2/version scopetest/scope /dependency注意JUnit 5的artifactId不是junit而是junit-jupiter这是一个聚合依赖包含了API、参数化测试和测试引擎。如果之前你用过junit-jupiter-api那是不够的因为IDEA和Maven运行测试时还需要junit-jupiter-engine。直接用junit-jupiter省心。Gradle项目则在build.gradle里加dependencies { testImplementation org.junit.jupiter:junit-jupiter:5.10.2 }如果是Spring Boot项目更省事。spring-boot-starter-test已经帮你打包好了JUnit 5、Mockito、AssertJ等常用测试库dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency这个依赖是Spring Boot 2.2之后默认使用JUnit 5之前是JUnit 4细节不同但基本用法一致。1.3 没有构建工具怎么加Jar包如果你没有用Maven/Gradle就是纯粹的IDEA项目那需要手动把JUnit的jar包加到工程里。简单做法是写Test后光标停在Test上按Alt EnterIDEA会弹出“Add JUnit to classpath”之类的快捷选项点一下它就会自动下载并引入。这是最不需要动脑的方法。但我建议尽早接触Maven或Gradle因为真实的团队项目不会用这种方式管理依赖。手动加jar包只适合临时写个小demo因为一旦依赖变多版本冲突就会成为灾难。2. 编写测试类的正确姿势注解、断言与命名2.1 Test的基本用法方法权限、返回类型、异常Test标记的方法需要满足约束不能是private不能有参数返回值最好声明为void。JUnit 4要求测试方法必须是public voidJUnit 5放宽了访问权限不用写public也能跑。如果一个方法有返回值JUnit会照常执行但不会去校验返回值所以通常没必要写返回类型。示例import org.junit.jupiter.api.Test; class DemoTest { Test void shouldReturnTrue() { // 这里是测试逻辑 } }还有一个常见的误区很多人以为测试方法名必须以test开头。JUnit 4时代确实有约定但加了Test注解后方法名可以随意。现在主流写法是直接用业务描述比如shouldReturnTrueWhenInputValid可读性更好。2.2 断言方法怎么选assertEquals、assertTrue、assertThrows等Test本身不包含任何判断逻辑真正判断“测试是否通过”的是断言。JUnit 4中静态导入org.junit.Assert.*JUnit 5中导入org.junit.jupiter.api.Assertions.*。常用的有这几个assertEquals(4, calculator.add(2, 2), 加法结果不对); assertTrue(list.isEmpty()); assertFalse(user.isActive()); assertNull(result); assertNotNull(result); assertThrows(IllegalArgumentException.class, () - { calculator.divide(1, 0); });JUnit 5的assertEquals还可以传第三个参数即失败时显示的消息这个对排错非常有用。assertThrows用于验证异常替代了JUnit 4里的Test(expected XxxException.class)推荐优先用assertThrows因为还能继续断言异常的信息。2.3 测试类命名与包结构约定测试类最好和被测试类放在同一个包下但放在src/test/java目录里。比如com.example.service.UserService测试类就是src/test/java/com/example/service/UserServiceTest。命名上一般是被测类名加Test后缀这是Maven Surefire默认扫描规则的一部分。为什么要放在相同包因为JUnit能看到包级私有成员。虽然我们一般不直接测私有方法但同包的设计本身更符合“测试与源码结构对齐”的原则。IDEA也能自动识别这种结构右键类名直接跳转到测试类。3. IDEA里运行Test的完整实操从单个方法到整个模块3.1 三种运行方式行号左侧运行、右键运行、快捷键运行写完测试类运行方式很简单。第一种在测试方法左侧的行号区域会出现一个绿色三角形图标点击它选择“Run 方法名()”就会执行当前这个单个测试方法。第二种在测试类的类名左侧或者右键点击类名选择“Run 类名”会运行这个类里的所有Test方法。第三种用快捷键。Windows/Linux下是Ctrl Shift F10macOS下是Control Shift R。这个快捷键的运行逻辑很智能光标在哪个测试方法上就运行哪个方法光标在类中但没有选中具体方法就会运行整个类。运行过一次之后可以直接按Shift F10macOS对应Control R重新运行上一次的测试配置。个人建议把首选项设为“Run tests using IntelliJ IDEA”而不是Gradle或Maven。位置在Settings - Build, Execution, Deployment - Build Tools - Gradle - Runner把“Run tests using”改成“IntelliJ IDEA”。因为直接用IDEA运行测试速度比起Gradle/Maven冷启动快很多而且结果展示更直观。但注意改成IDEA运行后某些只在Gradle/Maven里配置的测试环境变量可能不生效比如依赖Gradle过滤的资源文件这时候要回到构建工具运行。3.2 运行配置里的关键选项JUnit vs JUnit5大部分时候不需要手动创建运行配置IDEA会生成临时的JUnit配置。但如果你经常测试某个特定包或指定测试类可以打开Run - Edit Configurations点击左上角加号选择JUnit。这里有几个值得留意的配置项Test kind可以选择Class、Method、Package、Category等。Class / Method指定要运行的类和具体方法。VM options在这里可以加-Dfile.encodingUTF-8这类JVM参数。Working directory默认是项目根目录如果测试依赖文件路径需要确认这里是否正确。Use classpath of module选择对应的模块。如果是JUnit 5项目IDEA依然用“JUnit”配置类型不需要单独选“JUnit5”。IDEA会自动识别classpath中的JUnit平台并调起测试引擎。3.3 查看测试结果窗口进度条、统计、失败堆栈运行后底部会弹出“Run”工具窗口。绿色进度条表示全部通过红色表示存在失败。左边树状列表会列出所有测试方法点开某个失败的方法右侧是清晰的差异对比Expected和Actual的值如果断言时传了消息还会显示自定义的提示。真正的排错重点在“Failure”或者“Error”区分上。Failure是断言失败表示结果和预期不一致Error是测试执行过程中抛出了未捕获的异常一般是代码本身有问题。看堆栈信息时不要只看第一行往下翻到“Caused by”那里才有根本原因。3.4 条件跳过TestDisabled、EnabledIf等有时候测试还没写完或者依赖外部环境不想让它在CI里挂掉可以用Disabled跳过。JUnit 4里的注解是Ignore。Disabled(这里注释原因比如临时跳过等待接口联调完成) Test void notReadyTest() { // ... }JUnit 5还提供了更多条件注解比如EnabledOnOs(OS.WINDOWS)只让测试在Windows上跑EnabledIfEnvironmentVariable根据环境变量决定是否执行。日常开发中用得不多但CI中控制测试范围时很实用。4. 测试与构建工具集成Maven Surefire的坑4.1 mvn test 和IDEA运行Test的区别IDEA里的“运行”只是调起JUnit引擎并不会触发Maven的test生命周期。而mvn test会走完整的Maven流程编译、复制资源、运行Surefire插件再执行测试。两者最大的区别在于“环境”。如果你在pom.xml的build plugins里配置了插件比如maven-resources-plugin做资源替换或者maven-antrun-plugin生成文件那么只有mvn test才会触发这些过程。所以会出现一种情况IDEA里测试全绿mvn test却挂了。排查思路不是怀疑测试代码而是对比两边的运行环境最常见的差异是src/test/resources里的文件没有在IDEA中被正确复制到target/test-classes或者Maven配置的filter导致配置项不同。我的习惯是小步快速调试用IDEA提交代码前用mvn test全量跑一遍双保险。4.2 解决“There are test failures”导致install失败Maven在执行mvn install或mvn package时会触发测试一旦有测试失败默认会终止构建日志里会看到类似There are test failures并给出surefire报告的路径比如e:\source\usercenter\target\surefire-reports。看到这个别慌。先打开target/surefire-reports目录里面有.txt和.xml格式的测试报告比控制台输出更完整。优先看最近的失败测试类和方法名。如果你确认失败原因是环境问题比如测试需要连一个不存在的数据库而本地没有启动你可以选择跳过测试但如果是代码逻辑问题建议老实修复因为跳过测试只是把质量风险往后挪。4.3 跳过测试的正确姿势-DskipTests和-Dmaven.test.skiptrue经常有人问“IDEA在install的时候怎么跳过test”。其实关键参数有两个mvn install -DskipTests-DskipTests会跳过测试的执行但仍然会编译测试类。也就是说测试代码有语法错误时这个命令依然会失败。mvn install -Dmaven.test.skiptrue-Dmaven.test.skiptrue是更彻底的方式连测试代码的编译都跳过。这两个参数都有效但日常推荐-DskipTests因为它不会掩盖测试代码的编译问题。如果你嫌每次敲命令麻烦可以在IDEA的Maven工具窗口里找到“Toggle Skip Tests Mode”按钮点击后Maven会自动带上-DskipTests。或者打开Run - Edit Configurations在Maven运行配置的Command line里手动填参数。注意跳过测试只是临时手段。如果提交到CICI通常会单独跑测试任务这种参数不应该固化在pom.xml里否则等于废掉了自动化测试。5. 实战案例在Spring Boot项目里写一个带Test的接口测试5.1 引入spring-boot-starter-test并理解核心组件Spring Boot项目的测试不是单纯调一个方法而是要验证依赖注入、数据库连接、Controller路由等。spring-boot-starter-test包含了JUnit 5、Spring Test、AssertJ、Hamcrest、Mockito、JSONAssert等。这意味着你不必再手动添加JUnit依赖。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency添加后还需要标注SpringBootTest。这个注解会启动Spring上下文相当于在测试中把整个应用组装起来。代价是启动较慢所以如果只是想测一个Service方法可以不用SpringBootTest直接new出对象来测速度可能快很多。但涉及到Spring AOP、事务、自动配置时还是得靠它。5.2 写一个简单的Service单元测试假设有一个UserService里面有个方法判断用户是否为VIPService public class UserService { public boolean isVip(User user) { return user.getLevel() 3; } }对应的测试类可以这样写import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; class UserServiceTest { private final UserService userService new UserService(); Test void shouldReturnTrueWhenLevelGreaterThanOrEqualThree() { User vipUser new User(); vipUser.setLevel(3); assertTrue(userService.isVip(vipUser)); } Test void shouldReturnFalseWhenLevelLessThanThree() { User normalUser new User(); normalUser.setLevel(2); assertFalse(userService.isVip(normalUser)); } }这里不需要启动Spring因为UserService不依赖其他Bean。单元测试的重点是“只测当前类”外部依赖用Mock替代。5.3 写一个MockMvc的Web层测试再进一步测Controller。假设有UserControllerRestController RequestMapping(/users) public class UserController { GetMapping public ListUser list() { return List.of(new User(张三), new User(李四)); } }使用MockMvc可以在不真正启动Web服务器的情况下模拟HTTP请求import org.junit.jupiter.api.Test; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.test.web.servlet.MockMvc; import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get; import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*; SpringBootTest AutoConfigureMockMvc class UserControllerTest { Autowired private MockMvc mockMvc; Test void shouldReturnUserList() throws Exception { mockMvc.perform(get(/users)) .andExpect(status().isOk()) .andExpect(jsonPath($.length()).value(2)) .andExpect(jsonPath($[0].name).value(张三)); } }jsonPath是用来解析JSON响应体的表达式语言断言接口返回结构非常方便。这里建议用AutoConfigureMockMvc因为它只需要加载Web层相关的配置比启动完整上下文更快。如果项目里大量使用SpringBootTest导致测试很慢可以考虑切换到WebMvcTest只测Controller层再配合MockBean模拟Service。5.4 测试覆盖率怎么查看IDEA自带覆盖率工具不需要额外装插件。在测试类或其运行配置上右键选择“Run with Coverage”运行完IDEA会在编辑器左侧显示绿色和红色条绿色表示覆盖到的行红色表示没有覆盖到。打开覆盖率窗口还能看到类、方法、行覆盖率的百分比。覆盖率不用迷信100%。业务逻辑里容易出Bug的分支比如异常处理、边界条件优先覆盖。而getter/setter这种只有赋值和取值的代码覆盖率覆盖率低一点也无妨。IDEA的覆盖率工具还有一个“Add coverage to test suite”的功能能把多次运行的覆盖率合并在一起适合统计多个测试类整体覆盖情况。6. 常见问题与避坑经验我踩过的那些坑6.1 Test标红找不到符号这个问题反复出现原因是项目classpath里没有JUnit依赖。解决路径有两条如果是Maven项目检查pom.xml是否真的引入了依赖引入后记得刷新Maven让IDEA重新导入。如果是Gradle项目点一下Gradle工具窗口里的刷新按钮。还有一种情况是依赖已经存在但IDEA缓存坏了可以执行File - Invalidate Caches / Restart清缓存重启。注意如果你的项目用的JUnit 5但网上教程让你导入org.junit.Test那会标红因为JUnit 5的包名是org.junit.jupiter.api.Test。二者千万别混。6.2 运行时报No tests found这种提示常见于点击了测试类的运行按钮却输出“No tests found”或类似信息。可能原因有这几种测试方法加了privateJUnit无法调用。测试方法有参数但没配合ParameterizedTest。测试类不在src/test/java目录下Surefire默认不扫描。IDEA里可以看到测试类图标是不是绿色的小人如果不是说明IDEA不认为它是测试类。项目命名空间里存在JUnit 4和JUnit 5的引擎冲突可以尝试清理target目录后再跑。另外一个非常隐蔽的原因IDEA运行配置里选择了“All in package”但包路径下有多个模块的类运行器没有找到匹配测试。这种情况删掉旧的运行配置重新点击测试方法左侧的绿色箭头生成一次配置基本就能解决。6.3 测试方法执行顺序乱JUnit的默认执行顺序不固定这是设计如此为了测试之间不依赖顺序。如果你确实需要按顺序跑JUnit 4可以用FixMethodOrder(MethodSorters.NAME_ASCENDING)按照方法名字母序JUnit 5用组合注解TestMethodOrder(MethodOrderer.OrderAnnotation.class) class OrderTest { Test Order(1) void first() { } Test Order(2) void second() { } }但我要提醒一句测试之间不该依赖执行顺序。如果非要有先后说明你的测试有状态共享。正确做法是在BeforeEach里重建状态而不是把状态写在static字段里。6.4 控制台中文乱码导致断言失败测试中如果打印中文日志或断言中文内容IDEA控制台出现乱码比较常见。这其实不是Test的问题而是JVM默认编码和IDEA控制台编码不一致。解决办法打开Help - Edit Custom VM Options如果提示没有文件就创建一个加上-Dfile.encodingUTF-8重启IDEA。在Run - Edit Configurations里给当前的测试配置加VM options-Dfile.encodingUTF-8。如果用的是Maven运行确认MAVEN_OPTS或者pom.xml的project.build.sourceEncoding设置为UTF-8。遇到中文断言失败时先别急着改业务代码很可能只是编码问题导致期望的“用户”和实际输出的“锟斤拷”不同。6.5 测试跑太久或者IDEA卡死如果一个测试类里有大量SpringBootTest每个测试都启动一次Spring容器IDEA和机器会非常吃力。解决思路是把SpringBootTest尽量放在一个抽象的基类上让多个测试类继承同一个上下文SpringContext是缓存的多个测试类共用同一个上下文会快很多。如果单个测试方法里用了Thread.sleep等待异步结果这是坏味道容易造成测试不稳定。尽量用awaitility这类库轮询等待设置超时否则一旦环境波动测试就会误报。还有一点测试方法里创建的临时文件、数据库连接、线程池记得在AfterEach或AfterAll里清理。否则跑一个模块后临时文件堆积或者连接池线程不释放轻则IDEA变慢重则下一次测试失败。6.6 关于跳过测试的几个理解误区最后再说一下跳过测试。我在实际项目开发里见过有人把“测试失败就跳过”当成默认操作这是很危险的。跳过测试会导致代码质量问题被隐藏尤其是CI流水线上一旦跳过条件写死在配置里后续的提交都不会再执行测试。正确的处理方式先看失败原因。如果是测试代码写得不对修测试如果是业务代码Bug修业务代码只有确认是环境导致比如依赖的外部服务没启动才在本地临时加-DskipTests并且提交代码前必须用完整测试回归。我个人在实际操作中还有个习惯Test方法里的断言一定要带上自定义消息。比如assertEquals(用户列表大小不对, 3, list.size())。这样测试失败时看IDEA的报告就能立刻知道是哪一步逻辑出了问题而不需要一行行debug。不要小看这个细节它能省下你排查测试失败的大量时间。另外如果你还在用JUnit 4建议尽早升级到JUnit 5。JUnit 5的assertThrows、assertTimeout、参数化测试都比JUnit 4顺手得多而且它不是新东西了绝大多数项目都已经切换过来了。从今天开始每次写测试类先问自己一句这个测试要锁定的行为是什么想清楚再写断言测试才能真正成为你代码里的安全网。
