当前位置:首页>java>JUnit5单元测试:给代码买份“保险”!提前发现bug不踩坑

JUnit5单元测试:给代码买份“保险”!提前发现bug不踩坑

  • 2026-10-28 09:00:16
JUnit5单元测试:给代码买份“保险”!提前发现bug不踩坑
昨天我们用Maven重构了学生系统,彻底告别了手动导jar包的烦恼。很多同学反馈:“项目结构清爽了,但测试还是用main方法,每次要写一堆重复的获取SqlSession、关闭资源的代码,而且结果要自己肉眼核对,一不小心就漏看bug!”
这个问题戳中了很多新手的痛点—— 用main方法测试效率低、代码冗余,还无法自动验证结果,很容易把bug带到后续开发中 。今天我们就来学习Java开发的“必备测试神器”——JUnit5,它能帮我们简化测试代码,自动执行测试用例,还能精准判断结果是否符合预期,就像给代码买了份“保险”,提前发现bug不踩坑!
今天咱们就从“为什么需要单元测试”出发,搞懂JUnit5的核心用法,再手把手给学生系统的MyBatis查询、删除功能编写测试用例,全程基于Maven项目实战,代码可直接复用~

PART 01

先吐槽:main方法测试的4个“致命缺陷”(直击核心痛点)
在学JUnit5之前,我们先细数main方法测试的弊端,这样才能更直观地感受到JUnit5的香:
缺陷1:代码冗余,重复劳动多
测试每个方法(比如查询、删除)都要重复写“获取SqlSession→获取Mapper→调用方法→关闭资源”的代码,测试代码比业务代码还多,纯属无效劳动。
缺陷2:无法自动验证结果,全靠肉眼核对
查询出学生列表后,要自己逐行看控制台输出是否正确;删除数据后,还要手动去数据库查询是否删除成功,效率极低,还容易看错。
缺陷3:无法批量执行,测试不全面
如果有10个方法需要测试,就得手动运行10次main方法,无法一键批量执行;而且很难覆盖边界场景(比如查询不存在的班级、删除空学号)。
缺陷4:测试代码与业务代码混杂,维护成本高
测试代码和业务代码都放在src/main/java目录下,项目变大后,很难区分哪些是业务代码、哪些是测试代码,后续修改和维护都麻烦。
核心结论:JUnit5的核心价值是“标准化单元测试”——帮我们简化测试代码、自动验证结果、批量执行测试用例,还能规范测试代码结构,让测试更高效、更全面,提前拦截bug!

PART 02

JUnit5基础:核心概念通俗解读
JUnit是Java领域最流行的单元测试框架,JUnit5是最新版本(兼容JUnit4,功能更强大)。入门只需要搞懂3个核心概念,大白话就能理解:
  1. 单元测试:测试“最小功能单元”
单元测试就是测试代码中最小的可独立运行的单元,比如一个方法(StudentMapper的queryStudentsByClass方法、batchDeleteStudents方法)。目的是验证这个方法在各种输入下的输出是否符合预期。
  1. 测试用例:一个“完整的测试场景”
一个测试用例就是一个带@Test注解的方法,对应一个测试场景。比如“测试查询存在的班级”“测试查询不存在的班级”“测试批量删除有效学号”,每个场景都对应一个测试用例。
  1. 断言:自动判断结果是否符合预期
断言是JUnit5的核心功能,用代码判断方法的实际输出是否等于预期输出。比如断言“查询高一(1)班的学生数量等于5”,如果实际数量是5,测试通过;如果不是,测试失败,控制台会直接报错。

PART 03

实战:用JUnit5测试学生系统(核心步骤)
接下来是重点!我们基于第五天的Maven学生系统,集成JUnit5,给StudentMapper的查询、批量删除功能编写测试用例,全程5步搞定,彻底告别main方法测试~
前置准备:Maven项目结构(已完成第五天重构,直接复用)
重点关注测试代码目录:src/test/java(Maven约定的测试源代码目录,自动创建,无需手动标记),所有测试类都放在这个目录下,与业务代码(src/main/java)彻底分离。
步骤1:在pom.xml中导入JUnit5依赖
JUnit5的依赖已经被Maven中央仓库收录,只需在pom.xml的标签中添加以下依赖,Maven会自动下载:
<!-- JUnit5核心依赖(测试用例执行) -->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.9.2</version>
<scope>test</scope><!-- 仅在测试环境生效,打包时不包含 -->
</dependency>

<!-- JUnit5运行时依赖(让IDEA能执行测试用例) -->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.9.2</version>
<scope>test</scope>
</dependency>
说明:scope="test"表示这些依赖只在src/test/java目录下生效,不会被打包到最终的war包中,避免冗余。添加完依赖后,右键pom.xml → Maven → Reload Project,确保依赖下载完成。
步骤2:编写测试基类(抽取重复代码,简化测试)
测试每个方法都需要“获取SqlSession→获取Mapper→关闭SqlSession”,我们可以编写一个测试基类,用JUnit5的生命周期注解抽取这些重复代码,让测试用例更简洁:
package com.test;

import com.dao.StudentMapper;
import com.util.MyBatisUtil;
import org.apache.ibatis.session.SqlSession;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;

// 测试基类(所有测试类都可以继承,抽取重复代码)
publicclassBaseTest{
protected SqlSession sqlSession; // 保护级,子类可直接使用
protected StudentMapper studentMapper;

// @BeforeEach:每个测试用例执行前都会执行(初始化资源)
@BeforeEach
voidsetUp(){
// 获取SqlSession
        sqlSession = MyBatisUtil.getSqlSession();
// 获取StudentMapper代理对象
        studentMapper = sqlSession.getMapper(StudentMapper.class);
        System.out.println("=== 测试用例开始执行 ===");
    }

// @AfterEach:每个测试用例执行后都会执行(释放资源)
@AfterEach
voidtearDown(){
// 关闭SqlSession
if (sqlSession != null) {
            sqlSession.close();
        }
        System.out.println("=== 测试用例执行结束 ===");
    }
}
核心注解说明:
@BeforeEach:每个测试用例(@Test方法)执行前都会触发,用于初始化资源(获取SqlSession、Mapper);
@AfterEach:每个测试用例执行后都会触发,用于释放资源(关闭SqlSession);
继承基类后,所有测试子类都不用重复写初始化和释放资源的代码,专注于测试逻辑即可。
步骤3:编写测试用例(测试查询和批量删除功能)
创建com.test.StudentMapperTest类,继承BaseTest,编写4个测试用例,覆盖正常场景和边界场景:
package com.test;

import com.pojo.Student;
import org.junit.jupiter.api.Test;
importstatic org.junit.jupiter.api.Assertions.*; // 导入断言方法

import java.util.List;
import java.util.stream.Collectors;

// 学生Mapper测试类(继承BaseTest,复用资源初始化代码)
publicclassStudentMapperTestextendsBaseTest{

// 测试1:查询存在的班级(正常场景)—— 预期返回非空列表,数量正确
@Test
voidtestQueryStudentsByClass_Exist(){
// 1. 调用要测试的方法(查询高一(1)班)
        List<Student> studentList = studentMapper.queryStudentsByClass("高一(1)班");

// 2. 用断言验证结果(核心!自动判断是否符合预期)
        assertNotNull(studentList, "查询结果不应为空"); // 断言列表非空
        assertTrue(studentList.size() > 0, "高一(1)班应存在学生"); // 断言数量>0

// 可选:打印结果,辅助查看
        List<String> names = studentList.stream().map(Student::getName).collect(Collectors.toList());
        System.out.println("高一(1)班学生姓名:" + names);
    }

// 测试2:查询不存在的班级(边界场景)—— 预期返回空列表
@Test
voidtestQueryStudentsByClass_NotExist(){
// 1. 调用要测试的方法(查询高三(9)班,假设不存在)
        List<Student> studentList = studentMapper.queryStudentsByClass("高三(9)班");

// 2. 断言验证
        assertNull(studentList, "查询不存在的班级应返回空列表"); // 断言列表为空
    }

// 测试3:批量删除有效学号(正常场景)—— 预期删除成功,影响行数正确
@Test
voidtestBatchDeleteStudents_ValidIds(){
// 1. 准备测试数据(要删除的学号,确保存在)
        List<String> validIds = List.of("2024006", "2024007");

// 2. 调用要测试的方法
int deleteCount = studentMapper.batchDeleteStudents(validIds);

// 3. 断言验证(预期删除2条数据)
        assertEquals(2, deleteCount, "批量删除有效学号应影响2行数据");
    }

// 测试4:批量删除无效学号(边界场景)—— 预期删除失败,影响行数为0
@Test
voidtestBatchDeleteStudents_InvalidIds(){
// 1. 准备测试数据(不存在的学号)
        List<String> invalidIds = List.of("999999", "888888");

// 2. 调用要测试的方法
int deleteCount = studentMapper.batchDeleteStudents(invalidIds);

// 3. 断言验证(预期影响0行)
        assertEquals(0, deleteCount, "批量删除无效学号应影响0行数据");
    }
}
核心知识点:常用断言方法(必掌握)
断言是JUnit5的核心,上面的代码用到了4个常用断言,整理成表格方便记忆:

断言方法

作用

示例

assertNotNull(对象)

断言对象不为null

assertNotNull(studentList) —— 学生列表不应为空

assertNull(对象)

断言对象为null

assertNull(studentList) —— 不存在的班级应返回空列表

assertEquals(预期值, 实际值)

断言实际值等于预期值(适用于数字、字符串等)

assertEquals(2, deleteCount) —— 预期删除2条数据

assertTrue(条件)

断言条件为true

assertTrue(studentList.size()>0) —— 学生数量应大于0

步骤4:执行测试用例(IDEA操作)
JUnit5的测试用例可以单个执行,也可以批量执行,操作非常简单:
单个执行:在测试方法(比如testQueryStudentsByClass_Exist)左侧,点击绿色小三角→Run,即可执行该测试用例;
批量执行:在测试类(StudentMapperTest)左侧,点击绿色小三角→Run,即可执行该类中所有测试用例;
全局批量执行:右键src/test/java目录→Run Tests,即可执行项目中所有测试用例。
测试结果分析
  1. 测试通过:控制台显示绿色对勾,输出“Tests passed”,说明方法逻辑正确;
  2. 测试失败:控制台显示红色叉号,明确指出哪个断言失败(比如“expected: <2> but was: <1>”),还会显示异常堆栈,帮你快速定位问题;
  3. 对比main方法:不用手动写资源管理代码,不用肉眼核对结果,批量执行只需一键,测试效率提升10倍!

PART 04

进阶:JUnit5测试生命周期(优化测试逻辑)
除了@BeforeEach和@AfterEach,JUnit5还有几个常用的生命周期注解,用于更灵活地管理测试资源(比如测试前初始化测试数据、测试后清理数据):

注解

作用

使用场景

@BeforeAll

所有测试用例执行前执行一次(静态方法)

初始化全局资源(比如创建测试数据库表)

@AfterAll

所有测试用例执行后执行一次(静态方法)

清理全局资源(比如删除测试数据库表)

@Disabled

禁用某个测试用例(不执行)

测试用例暂未完成,或某个场景暂时不需要测试

示例:用@BeforeAll初始化测试数据(静态方法):
import org.junit.jupiter.api.BeforeAll;

publicclassStudentMapperTestextendsBaseTest{

// 所有测试用例执行前,初始化测试数据(只执行一次)
@BeforeAll
staticvoidinitTestData(){
// 示例:往学生表插入2条测试数据(实际开发中可调用Mapper方法)
        System.out.println("=== 初始化测试数据 ===");
    }

// 其他测试用例...
}

PART 05

避坑指南:JUnit5入门的5个高频错误(必看)
JUnit5的错误大多和注解使用、依赖配置相关,整理了5个高频错误,提前避开:
错误1:依赖导入错误,导致无法识别@Test注解
现象:IDEA报错“Cannot resolve symbol Test”,测试方法左侧没有绿色小三角。
解决:确保pom.xml中导入了junit-jupiter-api和junit-jupiter-engine两个依赖,且版本一致(推荐5.9.2);右键pom.xml → Maven → Reload Project,重新下载依赖。
错误2:测试方法命名错误或修饰符错误
现象:测试用例无法执行,控制台提示“No tests found”。
解决:测试方法必须满足3个条件:① 方法名任意(推荐以test开头);② 返回值为void;③ 无参数;④ 修饰符为public(JUnit5可省略,但推荐加上)。
错误3:@BeforeAll/@AfterAll注解用在非静态方法上
现象:报错“@BeforeAll method must be static”。
解决:@BeforeAll和@AfterAll注解的方法必须是静态方法(加上static关键字),因为它们在测试类初始化时执行,此时对象还未创建。
错误4:断言条件写反,导致测试误判
现象:明明方法逻辑正确,测试却失败。
解决:注意断言的参数顺序——assertEquals(预期值, 实际值),不要写反(比如把实际值放在前面,预期值放在后面); assertTrue的条件要符合业务逻辑(比如查询存在的班级,条件是size>0)。
错误5:测试数据污染,导致测试结果不稳定
现象:第一次执行测试通过,第二次执行失败。
解决:测试用例要保持“独立性”,每个测试用例执行前初始化干净的测试数据,执行后清理数据(可用@BeforeEach/@AfterEach实现);避免测试用例之间相互依赖(比如测试删除依赖测试新增的结果)。

PART 06

总结:JUnit5的核心价值与后续方向
今天我们用JUnit5给学生系统编写了测试用例,核心收获:
JUnit5简化了测试代码,通过生命周期注解抽取重复的资源管理代码,让测试更专注于逻辑;
通过断言实现结果自动验证,告别肉眼核对,精准发现bug;
支持批量执行测试用例,覆盖正常场景和边界场景,让代码更健壮。
有了单元测试这个“保障”,后续开发复杂功能时会更有底气!明天我们将正式进入Spring框架的学习——Spring是JavaWeb开发的“基石”,能帮我们解决代码耦合的问题,让项目更易于维护和扩展!
今天的JUnit5测试用例你都跑通了吗?如果遇到@Test注解识别不了、测试用例无法执行等问题,欢迎在评论区留言,我会逐一回复~ 觉得有用的话,记得点赞、在看、转发给身边学JavaWeb的同学哦!
往期回顾:
#Java 基础入门      #Java 进阶核心#JavaWeb 开发
对啦~还没锁定「咖啡 java 研习室」的小伙伴看这里!点击上方公众号卡片关注后,在对话框回复「学习资料」,就能领取 Java 从入门到进阶的干货资料包啦~

最新文章

随机文章