说实话很多人学到 JavaSE 阶段会有一个共同的困惑代码写得越来越长工具类、业务逻辑堆了一堆靠main方法里System.out.println验证结果的方式越来越吃力。改了一个方法的行为你根本不知道还有哪些地方在依赖它改完心里完全没底。我第一次真正意识到“不能这么干下去了”是因为写一个订单金额计算工具类改计价规则时不小心动到了另一个方法结果线下功能全乱愣是排查了一下午。后来我才开始系统接触 JUnit 测试框架把自己从“不敢改代码”的状态里解放出来。JUnit 是 Java 生态里最经典的单元测试框架在 JavaSE 阶段学会它不是说让你成为一个测试工程师而是让你在写业务代码的时候就能顺手给自己铺一张安全网。这篇内容我会从最基础的环境搭建开始讲到生命周期、断言、参数化测试、动态测试再到真实编码时容易踩的坑把我在 JavaSE 教学和实际项目中总结的经验一次性讲透。1. 从“不敢改代码”到“放心重构”JavaSE阶段为什么要引入JUnit1.1 大多数新手的“打印大法”问题出在哪很多初学者第一次接触验证代码的正确性靠的都是main方法public class Calculator { public int add(int a, int b) { return a b; } public static void main(String[] args) { Calculator calc new Calculator(); System.out.println(calc.add(2, 3)); // 看到输出 5觉得没问题完事 } }这种写法在代码量小的时候确实够用。但一旦类的方法变多尤其是方法之间有相互调用问题就开始暴露了。你不可能为了验证一个方法反反复复改main方法里的测试数据更麻烦的是这些验证代码最终会残留下来让类变得臃肿还会在项目构建时产生一堆毫无意义的输出。更关键的是打印出来的结果靠人眼判断这本身就是不靠谱的。你今天看到add(2, 3)输出 5觉得没问题但哪天有人把add方法的实现改成了return a - b;你还得靠肉眼重新看一遍输出才能发现异常。浪费时间不说还极其容易漏掉。1.2 JUnit解决的是“可持续验证”问题JUnit 这类单元测试框架本质上是把“验证代码行为”这件事自动化。你可以为每个方法编写对应的测试方法用断言机制自动判断结果是否符合预期。绿色代表全部通过红色代表至少有一个失败跑一次就能看到结果不需要人肉比对输出。这套机制带来的最大收益是重构时的安全感。JavaSE 阶段你可能还体会不深但当你开始写稍微复杂一点的项目比如一个学生管理系统、一个文件解析工具你就会发现改一个公共方法的行为影响范围往往超出你的预期。有了单元测试你可以在修改后一键运行所有测试哪里挂了立刻就能定位而不需要靠记忆和翻代码去猜测哪些地方受影响。我在带新人时常用一个比喻单元测试就像是你写代码时给自己系的安全带平时感觉不到它的存在真出问题的时候它是能救命的。1.3 别神化JUnit它不是万能锤子JUnit 适合测试的是纯逻辑、工具类、算法、解析器、服务层的业务规则特点是不依赖外部环境运行快结果稳定。JavaSE 阶段绝大部分代码都符合这个条件所以特别适合在这个阶段养成写测试的习惯。但也要说清楚JUnit 本身不擅长处理那些强依赖外部资源的情况比如连数据库、调远程接口、读写真实文件系统。这类测试跑起来慢而且环境一变就容易挂属于集成测试范畴需要配合 Mock 工具来处理。这部分内容 JavaSE 阶段接触不多但心里要有个数免得以后写测试写不下去时怀疑是自己方法不对。2. 版本选型与基础工程搭建JUnit 4还是JUnit 5为什么推荐直接上手JUnit 52.1 两代框架的分水岭在哪很多老教程还在讲 JUnit 4导致初学者经常混淆。JUnit 4 是上一代的事实标准它用Test注解、Before、After、BeforeClass、AfterClass来标记测试生命周期用Assert类里的静态方法做断言用RunWith扩展框架。这套 API 设计在当年非常优秀放到现在也不算过时。JUnit 5 是当前的主流版本也是新项目的默认选择。它的架构做了一个很大的拆分底层是 JUnit Platform它定义了测试框架如何被 IDE 和构建工具发现和执行真正写测试时用到的注解和断言在 Jupiter 模块里如果还想兼容老代码里的 JUnit 4 测试则通过 Vintage 模块来运行。我为什么建议 JavaSE 阶段直接学 JUnit 5原因很简单你现在学的东西应该尽量是未来几年还用得上的。JUnit 5 在 JUnit 4 的基础上增加了太多有价值的特性——Lambda 风格的断言、参数化测试内置支持、动态测试、嵌套测试、更灵活的生命周期管理。这些特性可以让测试代码写得更简洁、更强大。而且现在 IntelliJ IDEA、Eclipse、Maven、Gradle 对 JUnit 5 的支持都已经非常成熟完全不存在兼容性问题。2.2 在Maven工程里引入JUnit 5依赖如果你还没有用 Maven 或 Gradle 管理项目建议从现在开始就把这个习惯建立起来。手工下载 jar 包往项目里塞的做法在真实团队里几乎已经消失了。这里以 Maven 为例在pom.xml里加入这段依赖properties junit.jupiter.version5.10.2/junit.jupiter.version /properties dependencies dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version${junit.jupiter.version}/version scopetest/scope /dependency /dependencies注意这里用的是junit-jupiter这个聚合坐标它会自动把junit-jupiter-api写测试用的注解和断言、junit-jupiter-params参数化测试支持、junit-jupiter-engine测试执行引擎都带进来。新手不需要纠结要不要单独引api或engine直接这一个依赖就够了。scope设为test表示这个依赖只在测试编译和运行阶段存在不会被打进最终的产物里。如果你用的是 Spring Boot 项目那更省事spring-boot-starter-test里面已经内置了 JUnit 5不需要额外添加。2.3 第一个测试类的诞生假设我们要给一个简单的计算器类写测试。先写业务类public class Calculator { public int add(int a, int b) { return a b; } public int subtract(int a, int b) { return a - b; } }然后创建测试类。一定要遵守 Maven 的标准目录结构测试代码放在src/test/java目录下包名和业务类保持一致。这样做的原因是第一Maven 构建时会自动把这个目录下的类当作测试代码编译第二包名一致意味着测试类可以访问同包下的包私有成员方便测试。import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; class CalculatorTest { Test void addShouldReturnCorrectSum() { Calculator calculator new Calculator(); assertEquals(5, calculator.add(2, 3)); } }注意几个细节第一测试类名建议以Test结尾这是团队协作的默认约定Maven 的 Surefire 插件默认也会扫描这类文件第二测试方法用Test标注方法名用英文描述清楚行为意图比如addShouldReturnCorrectSum看到名字就知道它验证的是加法应该返回正确之和第三在 JUnit 5 里测试类和测试方法不强制要求public包私有就够了少写一个public没什么坏处。在 IDEA 里你会在测试类的方法行号旁边看到一个绿色的运行箭头点击它就可以运行当前测试方法右键测试类选择Run则运行整个类里的全部测试。运行结果如果是绿色条表示全部通过如果是红色条会告诉你哪个方法失败了、期望值是多少、实际值是多少。3. 核心注解与测试生命周期搞清楚每个方法什么时候跑、跑几次3.1 生命周期注解全解析JUnit 5 里有一组控制测试生命周期的注解它们的名字和用途如下注解使用场景是否必须为静态方法BeforeAll在执行当前测试类中所有测试方法之前执行一次通常用来做全局初始化JUnit 5 默认要求静态方法配合TestInstance(PER_CLASS)可以变成非静态AfterAll在执行当前测试类中所有测试方法之后执行一次通常用来释放全局资源同上BeforeEach在每个测试方法执行之前都执行一次用来准备测试对象、初始化测试数据不需要实例方法AfterEach在每个测试方法执行之后都执行一次用来清理数据、释放资源不需要实例方法初学者最容易犯的错误是搞混BeforeAll和BeforeEach的触发次数。记住一个口诀All 是整个测试类只跑一次Each 是每个测试方法都跑一次。如果你的测试类里有 10 个测试方法BeforeAll只执行 1 次BeforeEach执行 10 次。3.2 通过实际输出理解执行顺序我建议你自己动手写一个类验证一下执行顺序这样比背任何文档都管用import org.junit.jupiter.api.*; class LifecycleTest { BeforeAll static void initAll() { System.out.println(BeforeAll: 整个测试类开始前执行一次); } AfterAll static void tearDownAll() { System.out.println(AfterAll: 整个测试类结束后执行一次); } BeforeEach void init() { System.out.println(BeforeEach: 每个测试方法前执行); } AfterEach void tearDown() { System.out.println(AfterEach: 每个测试方法后执行); } Test void testOne() { System.out.println(执行测试方法 one); } Test void testTwo() { System.out.println(执行测试方法 two); } }运行结果会是这样BeforeAll: 整个测试类开始前执行一次 BeforeEach: 每个测试方法前执行 执行测试方法 one AfterEach: 每个测试方法后执行 BeforeEach: 每个测试方法前执行 执行测试方法 two AfterEach: 每个测试方法后执行 AfterAll: 整个测试类结束后执行一次不过有个前提就是 IDEA 默认的执行顺序可能按照方法名字符串来排testOne会先于testTwo执行。如果你在真实环境中发现顺序不稳定别慌测试方法之间本来就不应该依赖执行顺序。3.3 为什么测试之间必须完全隔离理解生命周期之后接下来一个重要概念就是测试隔离。JUnit 5 默认对每个测试方法都会创建一个新的测试类实例这意味着你在testOne里给成员变量赋的值在testTwo里是看不到的。这种设计是故意的——要保证每个测试方法都是独立运行的互不干扰。来一个反例让大家感受一下class BadTest { private int count 0; Test void test1() { count count 1; assertEquals(1, count); } Test void test2() { count count 1; assertEquals(1, count); } }因为count是从初始值 0 开始的两个测试方法各自都是在自己的实例上运算所以test1和test2都能通过。这就是 JUnit 5 默认PER_METHOD生命周期带来的好处。如果这是一个static int count两个测试就会共享这个变量那test1执行完后count变成 1test2执行时再1就变成 2断言assertEquals(1, count)就会挂掉。这就是典型的静态状态污染后面我会专门讲这个坑。但有些场景下我们希望BeforeAll不是静态方法比如想在初始化时访问实例变量那可以给测试类加上TestInstance(TestInstance.Lifecycle.PER_CLASS)让整个测试类只创建一个实例所有测试方法共享这个实例。这样BeforeAll和AfterAll就不必是静态方法了。但除非有明确的理由否则不建议新手这么做默认的每个方法一个实例能避免很多诡异的问题。4. 断言不是装饰品Assertions API的正确打开方式4.1 assertEquals 的参数顺序陷阱在 JUnit 5 里assertEquals最常用的重载是assertEquals(expected, actual)第一个参数是期望值第二个参数是实际值。新手经常写反变成assertEquals(calculator.add(2, 3), 5)。如果你把实际值放在前面、期望值放在后面代码是能跑的因为这个方法的两个参数类型一样编译器不会报错但一旦失败JUnit 打印的提示信息就会让人摸不着头脑Expected :实际计算出来的值 Actual :你写死的期望值等于把期望和实际完全搞反了排查问题的时候要多转一道弯。所以从第一天起就养成正确的参数顺序这对调试体验的影响非常大。4.2 用 assertThrows 验证异常行为除了验证正常的返回值我们经常还需要验证“这个方法在特定输入下应该抛异常”。很多老代码里是这么写的Test void divideByZeroShouldThrow() { try { calculator.divide(1, 0); fail(这里不应该执行到); } catch (ArithmeticException e) { // 捕获到异常测试通过 } }这种写法的问题在于如果你忘了调用fail()当异常没有抛出来时测试也会通过但这并不是你想要的结果。JUnit 5 提供了更优雅的assertThrowsimport static org.junit.jupiter.api.Assertions.assertThrows; Test void divideByZeroShouldThrow() { ArithmeticException exception assertThrows(ArithmeticException.class, () - calculator.divide(1, 0)); assertEquals(/ by zero, exception.getMessage()); }assertThrows会执行你传入的 Lambda 表达式如果表达式抛出了指定类型的异常测试通过并且返回这个异常对象你可以继续对异常内部的信息做断言如果没有抛出异常或者抛出的类型不匹配测试失败并给出明确提示。这是推荐的标准写法简洁、可读性强也避免了 try-catch 结构里容易漏写fail()的问题。4.3 超时断言与多重断言JUnit 5 提供了assertTimeout它可以验证一个操作是否在指定时间内完成import static org.junit.jupiter.api.Assertions.assertTimeout; import java.time.Duration; Test void shouldFinishWithinOneSecond() { assertTimeout(Duration.ofSeconds(1), () - { // 需要验证执行时间的业务逻辑 }); }这个功能适合用来验证算法性能是否符合预期或者防止代码出现死循环。但要注意assertTimeout等待的是一个线程在指定时间内完成在测试失败时其他代码可能还在后台继续运行容易造成测试之间的干扰。如果你只是想快速判断代码是否超时可以用assertTimeoutPreemptively它会强制中断超时的执行线程。但后者在线程本地变量、静态变量等场景下可能带来意料之外的问题建议优先用assertTimeout。还有一个很实用的断言是assertAll。它允许你在一个测试方法里同时执行多个断言即使前面某个断言失败了后面的断言也会继续执行最终把所有失败信息一次性汇总出来Test void userInfoShouldBeCorrect() { User user new User(张三, 25, zhangsanexample.com); assertAll(用户信息校验, () - assertEquals(张三, user.getName()), () - assertEquals(25, user.getAge()), () - assertEquals(zhangsanexample.com, user.getEmail()) ); }没有assertAll的时候一旦第一个断言失败后面的断言根本不会执行你只能修好一个问题重新跑一次再发现下一个问题。用assertAll可以一次看到所有失败项效率会高很多。4.4 失败消息怎么写才有价值assertEquals还支持传入第三个参数自定义失败消息。很多新手忽略了这个参数导致测试挂掉时只能看到一堆数字完全不知道为什么会失败、是哪个场景下失败。我个人的习惯是在涉及计算逻辑、复杂业务规则的时候一定要加上上下文信息。Test void discountShouldBeAppliedCorrectly() { double originalPrice 100.0; double discount 0.8; double expected 80.0; double actual priceCalculator.applyDiscount(originalPrice, discount); assertEquals(expected, actual, () - 计算折扣出错原价 originalPrice , 折扣 discount); }注意到这里我用了 Lambda 表达式() - ...而不是直接传字符串因为直接传字符串的话JVM 在每次断言时都会执行字符串拼接即使测试是通过的、根本用不到这个消息也要白白付出拼接的代价。用 Lambda 表达式可以做到惰性加载只有断言失败时才会真正执行字符串拼接。这个性能优化在测试量大的时候是有意义的。5. 参数化测试一份逻辑多组数据彻底告别复制粘贴5.1 没有参数化测试时你只能复制粘贴假设你要验证一个判断年份是否为闰年的方法正常的年份、世纪年、非世纪年、边界年份你至少得准备四五个测试数据。没有参数化测试的时候你不能在一个Test方法里塞多个用例因为那样第一个断言失败后面就不执行了你分不清到底是哪个用例出了问题。于是你只能复制好几个几乎一模一样的测试方法Test void isLeapYear_case1() { assertTrue(DateUtil.isLeapYear(2000)); } Test void isLeapYear_case2() { assertFalse(DateUtil.isLeapYear(1900)); }这种代码写起来烦维护起来更烦。哪天方法签名改了你要挨个去改所有复制出来的测试方法。JUnit 5 内置参数化测试就是专门用来解决这个问题的。5.2 三种常用数据源ParameterizedTest注解配合数据源注解可以让同一个测试逻辑跑多组数据。最常用的有三种ValueSource适合传单组简单数据比如基本类型和字符串ParameterizedTest ValueSource(ints {1, 2, 3, 4}) void testIntValues(int number) { assertTrue(number 0); }CsvSource适合传多组数据每个参数之间用逗号分隔可以传 null 和空字符串ParameterizedTest CsvSource({ 2000, true, 1900, false, 2024, true, 2023, false }) void leapYearShouldReturnExpectedResult(int year, boolean expected) { assertEquals(expected, DateUtil.isLeapYear(year)); }MethodSource最强大适合传复杂对象、集合、Stream以及参数个数不确定的场景。方法必须返回Stream、Iterable、Iterator或参数数组而且必须是非 private 的静态方法ParameterizedTest MethodSource(userProvider) void testUserValidation(User user, boolean expectedValid) { assertEquals(expectedValid, userValidator.isValid(user)); } static StreamArguments userProvider() { return Stream.of( Arguments.of(new User(张三, 25), true), Arguments.of(new User(, 25), false), Arguments.of(new User(张三, -1), false) ); }还有一个非常有用的参数ParameterizedTest(name {index} year{0}, expected{1})。这样你在测试报告里就能直接看到是哪一组参数失败了而不是只有一行模糊的testLeapYear失败信息。{0}代表第一个参数{1}代表第二个参数{index}是当前数据行的索引。5.3 参数化测试的命名与可读性用参数化测试还有一个额外的好处测试方法只需要写一个但从测试报告的角度看它会产生多条测试用例记录。配合自定义命名模板你能清楚地看到每条测试用例覆盖了什么场景这比在一个方法里用 for 循环断言要清晰得多。但这里有个很容易踩的坑参数化测试方法不能是 private数据源方法如果是MethodSource指定的也必须是 static 方法除非测试类标注了TestInstance(PER_CLASS)。有些新手把数据源方法写成实例方法编译就报错。如果是在 Java 8 以前的环境里还需要额外依赖junit-jupiter-params但我们是直接用junit-jupiter聚合依赖所以这一层的依赖问题已经帮大家省掉了。6. 动态测试与嵌套测试JUnit 5的进阶玩法6.1 Nested 让测试结构跟着业务逻辑走当你的业务类方法比较多或者一个业务的场景特别复杂时把所有测试方法平铺在一个类里会显得臃肿且难以阅读。JUnit 5 的Nested注解允许在一个测试类中创建内部测试类把相关的测试分组组织起来。比如我们有一个订单服务类包含下单、取消订单、查询订单等方法测试类可以这样组织class OrderServiceTest { OrderService orderService; BeforeEach void setUp() { orderService new OrderService(); } Nested class CreateOrder { Test void shouldCreateOrderWhenUserValid() { // ...下单正常逻辑 } Test void shouldThrowExceptionWhenUserInvalid() { // ...用户无效场景 } } Nested class CancelOrder { Test void shouldCancelOrderWhenStatusPending() { // ...待支付状态可取消 } Test void shouldNotCancelOrderWhenStatusShipped() { // ...已发货状态不可取消 } } }这样组织测试的好处是跑起来的时候 IDEA 的测试报告会显示清晰的层级结构你和团队其他成员一眼就能看出每个模块对应的测试覆盖情况。注意Nested内部类必须是非静态内部类而且 JUnit 5 中不加public修饰符也能正常工作。6.2 TestFactory 在运行时生成测试用例TestFactory可以让你在运行时动态生成测试用例返回值可以是DynamicTest的集合、流或数组。它特别适合那些输入数据直到运行时才能确定的场景或者你想在测试中对一批数据执行同一套逻辑并生成独立测试报告的场合。TestFactory StreamDynamicTest dynamicTestsForLeapYear() { ListInteger years Arrays.asList(2000, 1900, 2024, 2023); ListBoolean expectedResults Arrays.asList(true, false, true, false); return IntStream.range(0, years.size()) .mapToObj(i - dynamicTest( 验证年份 years.get(i) 是否为闰年, () - assertEquals(expectedResults.get(i), DateUtil.isLeapYear(years.get(i))) )); }运行这段代码测试报告里会显示四条独立的动态测试用例每条都有自己的名字。注意TestFactory方法本身不能是Test方法它只能标识在工厂方法上。这个方法很多新手容易混乱其实你只要记住一句话Test是提前把测试逻辑定死TestFactory是运行时由代码生成测试用例。7. 真实项目中容易踩的坑与解决办法7.1 静态可变状态的污染这是我在实际项目里见过最多的问题。新人在写测试时为了省事用静态变量保存状态结果测试之间就会通过静态变量互相影响。比如一个测试修改了静态配置另一个测试读到了被篡改的配置直接失败而且报错信息让你完全摸不着头脑。解决办法很简单测试代码里尽量避免使用可变的静态变量如果一定要用在BeforeEach或AfterEach里做重置。还有BeforeAll里做初始化时要特别注意这个初始化只执行一次对整个测试类里的所有方法都有效如果某个测试方法会修改这个静态状态后面的测试就会中招。最好的办法是让BeforeAll只初始化那些真正全局共享且不会被修改的资源。7.2 随机数据导致偶发失败有的同学在写测试时喜欢用Random生成测试数据结果某个测试方法偶尔会失败但不是每次都能复现。这种问题最耗时间因为你无法确定到底是什么数据触发了问题。我的经验是测试数据必须可复现。如果要用随机数一定要指定固定的随机种子Test void sortShouldHandleRandomInput() { Random random new Random(42); // 固定种子 int[] array new int[100]; for (int i 0; i array.length; i) { array[i] random.nextInt(); } // 断言排序结果 }固定种子后每次运行生成的随机序列完全相同失败了也能稳定复现。这条原则也适用于其他涉及时间、并发等不确定因素的测试。7.3 只测“快乐路径”不测边界条件很多初学者写测试时习惯性地只测试“正常情况”——输入合法数据得到预期结果。这种习惯很危险因为代码真正出问题往往是在边界空字符串、null、0、负数、极大值、浮点精度、集合为空、字符串超长。每次写完测试我都建议你专门停下来想一想这个方法在处理边界输入时会不会出问题然后把这些边界用例补进去。判断一个字段是否为空、一个数字是否在合法范围内这类校验逻辑特别适合参数化测试。把正常情况和边界情况全部列进去一份测试逻辑覆盖全部既省代码又能直观看到测试覆盖程度。7.4 测试代码也是要维护的代码很多项目里的测试代码到最后会变得一团糟原因在于大家把测试代码当成“二等公民”觉得它只要能跑就行。但测试代码是需要长期演进、经常运行的它的可读性直接影响整个团队的维护效率。我个人的习惯是测试方法名尽量做到“看图说话”一看就知道它在验证什么。国内团队用中文方法名也挺常见JDK 也支持中文标识符这个可以根据团队约定来。更推荐的做法是方法名描述行为比如shouldThrowExceptionWhenOrderStatusIsShipped。像test1、test2这种毫无信息量的方法名过了一个月你再回头看根本不知道它当时在测什么定位问题会非常痛苦。还可以在测试方法内部用注释把场景分为三段给定条件Given、执行操作When、验证结果Then。这个习惯能让你在写测试时思路更清晰也让读代码的人很容易理解测试的意图。写在最后的实操心得JUnit 上手其实很快真正的门槛是养成“先想测试、再写实现”或者“写完实现立刻补测试”的习惯。我在教 JavaSE 的时候一直跟学生强调一个观点代码跑通不代表正确正确性要靠测试来证明。你的时间不应该花在反反复复地打印输出、肉眼比对结果上而应该花在描述清楚“这段代码应该怎么表现才算正确”上——这个描述就是测试。给新手一个具体可落地的建议不要追求 100% 覆盖率那个指标在真实项目里意义不大。先把核心业务逻辑、边界条件、异常场景覆盖住比盲目堆一万个无意义的断言有用得多。从一个简单的工具类开始比如日期工具、金额计算、字符串处理每写一个方法就顺手补几个测试坚持一个月你一定能明显感觉到改代码时敢下手了重构时心里有底了。这种安全感的建立比会背多少 API 都重要。 
长河君 · 2026/9/9 8:06:55 · 阅读 1.2k JavaSE阶段JUnit单元测试实战：从断言到参数化测试
说实话很多人学到 JavaSE 阶段会有一个共同的困惑代码写得越来越长工具类、业务逻辑堆了一堆靠main方法里System.out.println验证结果的方式越来越吃力。改了一个方法的行为你根本不知道还有哪些地方在依赖它改完心里完全没底。我第一次真正意识到“不能这么干下去了”是因为写一个订单金额计算工具类改计价规则时不小心动到了另一个方法结果线下功能全乱愣是排查了一下午。后来我才开始系统接触 JUnit 测试框架把自己从“不敢改代码”的状态里解放出来。JUnit 是 Java 生态里最经典的单元测试框架在 JavaSE 阶段学会它不是说让你成为一个测试工程师而是让你在写业务代码的时候就能顺手给自己铺一张安全网。这篇内容我会从最基础的环境搭建开始讲到生命周期、断言、参数化测试、动态测试再到真实编码时容易踩的坑把我在 JavaSE 教学和实际项目中总结的经验一次性讲透。1. 从“不敢改代码”到“放心重构”JavaSE阶段为什么要引入JUnit1.1 大多数新手的“打印大法”问题出在哪很多初学者第一次接触验证代码的正确性靠的都是main方法public class Calculator { public int add(int a, int b) { return a b; } public static void main(String[] args) { Calculator calc new Calculator(); System.out.println(calc.add(2, 3)); // 看到输出 5觉得没问题完事 } }这种写法在代码量小的时候确实够用。但一旦类的方法变多尤其是方法之间有相互调用问题就开始暴露了。你不可能为了验证一个方法反反复复改main方法里的测试数据更麻烦的是这些验证代码最终会残留下来让类变得臃肿还会在项目构建时产生一堆毫无意义的输出。更关键的是打印出来的结果靠人眼判断这本身就是不靠谱的。你今天看到add(2, 3)输出 5觉得没问题但哪天有人把add方法的实现改成了return a - b;你还得靠肉眼重新看一遍输出才能发现异常。浪费时间不说还极其容易漏掉。1.2 JUnit解决的是“可持续验证”问题JUnit 这类单元测试框架本质上是把“验证代码行为”这件事自动化。你可以为每个方法编写对应的测试方法用断言机制自动判断结果是否符合预期。绿色代表全部通过红色代表至少有一个失败跑一次就能看到结果不需要人肉比对输出。这套机制带来的最大收益是重构时的安全感。JavaSE 阶段你可能还体会不深但当你开始写稍微复杂一点的项目比如一个学生管理系统、一个文件解析工具你就会发现改一个公共方法的行为影响范围往往超出你的预期。有了单元测试你可以在修改后一键运行所有测试哪里挂了立刻就能定位而不需要靠记忆和翻代码去猜测哪些地方受影响。我在带新人时常用一个比喻单元测试就像是你写代码时给自己系的安全带平时感觉不到它的存在真出问题的时候它是能救命的。1.3 别神化JUnit它不是万能锤子JUnit 适合测试的是纯逻辑、工具类、算法、解析器、服务层的业务规则特点是不依赖外部环境运行快结果稳定。JavaSE 阶段绝大部分代码都符合这个条件所以特别适合在这个阶段养成写测试的习惯。但也要说清楚JUnit 本身不擅长处理那些强依赖外部资源的情况比如连数据库、调远程接口、读写真实文件系统。这类测试跑起来慢而且环境一变就容易挂属于集成测试范畴需要配合 Mock 工具来处理。这部分内容 JavaSE 阶段接触不多但心里要有个数免得以后写测试写不下去时怀疑是自己方法不对。2. 版本选型与基础工程搭建JUnit 4还是JUnit 5为什么推荐直接上手JUnit 52.1 两代框架的分水岭在哪很多老教程还在讲 JUnit 4导致初学者经常混淆。JUnit 4 是上一代的事实标准它用Test注解、Before、After、BeforeClass、AfterClass来标记测试生命周期用Assert类里的静态方法做断言用RunWith扩展框架。这套 API 设计在当年非常优秀放到现在也不算过时。JUnit 5 是当前的主流版本也是新项目的默认选择。它的架构做了一个很大的拆分底层是 JUnit Platform它定义了测试框架如何被 IDE 和构建工具发现和执行真正写测试时用到的注解和断言在 Jupiter 模块里如果还想兼容老代码里的 JUnit 4 测试则通过 Vintage 模块来运行。我为什么建议 JavaSE 阶段直接学 JUnit 5原因很简单你现在学的东西应该尽量是未来几年还用得上的。JUnit 5 在 JUnit 4 的基础上增加了太多有价值的特性——Lambda 风格的断言、参数化测试内置支持、动态测试、嵌套测试、更灵活的生命周期管理。这些特性可以让测试代码写得更简洁、更强大。而且现在 IntelliJ IDEA、Eclipse、Maven、Gradle 对 JUnit 5 的支持都已经非常成熟完全不存在兼容性问题。2.2 在Maven工程里引入JUnit 5依赖如果你还没有用 Maven 或 Gradle 管理项目建议从现在开始就把这个习惯建立起来。手工下载 jar 包往项目里塞的做法在真实团队里几乎已经消失了。这里以 Maven 为例在pom.xml里加入这段依赖properties junit.jupiter.version5.10.2/junit.jupiter.version /properties dependencies dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version${junit.jupiter.version}/version scopetest/scope /dependency /dependencies注意这里用的是junit-jupiter这个聚合坐标它会自动把junit-jupiter-api写测试用的注解和断言、junit-jupiter-params参数化测试支持、junit-jupiter-engine测试执行引擎都带进来。新手不需要纠结要不要单独引api或engine直接这一个依赖就够了。scope设为test表示这个依赖只在测试编译和运行阶段存在不会被打进最终的产物里。如果你用的是 Spring Boot 项目那更省事spring-boot-starter-test里面已经内置了 JUnit 5不需要额外添加。2.3 第一个测试类的诞生假设我们要给一个简单的计算器类写测试。先写业务类public class Calculator { public int add(int a, int b) { return a b; } public int subtract(int a, int b) { return a - b; } }然后创建测试类。一定要遵守 Maven 的标准目录结构测试代码放在src/test/java目录下包名和业务类保持一致。这样做的原因是第一Maven 构建时会自动把这个目录下的类当作测试代码编译第二包名一致意味着测试类可以访问同包下的包私有成员方便测试。import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; class CalculatorTest { Test void addShouldReturnCorrectSum() { Calculator calculator new Calculator(); assertEquals(5, calculator.add(2, 3)); } }注意几个细节第一测试类名建议以Test结尾这是团队协作的默认约定Maven 的 Surefire 插件默认也会扫描这类文件第二测试方法用Test标注方法名用英文描述清楚行为意图比如addShouldReturnCorrectSum看到名字就知道它验证的是加法应该返回正确之和第三在 JUnit 5 里测试类和测试方法不强制要求public包私有就够了少写一个public没什么坏处。在 IDEA 里你会在测试类的方法行号旁边看到一个绿色的运行箭头点击它就可以运行当前测试方法右键测试类选择Run则运行整个类里的全部测试。运行结果如果是绿色条表示全部通过如果是红色条会告诉你哪个方法失败了、期望值是多少、实际值是多少。3. 核心注解与测试生命周期搞清楚每个方法什么时候跑、跑几次3.1 生命周期注解全解析JUnit 5 里有一组控制测试生命周期的注解它们的名字和用途如下注解使用场景是否必须为静态方法BeforeAll在执行当前测试类中所有测试方法之前执行一次通常用来做全局初始化JUnit 5 默认要求静态方法配合TestInstance(PER_CLASS)可以变成非静态AfterAll在执行当前测试类中所有测试方法之后执行一次通常用来释放全局资源同上BeforeEach在每个测试方法执行之前都执行一次用来准备测试对象、初始化测试数据不需要实例方法AfterEach在每个测试方法执行之后都执行一次用来清理数据、释放资源不需要实例方法初学者最容易犯的错误是搞混BeforeAll和BeforeEach的触发次数。记住一个口诀All 是整个测试类只跑一次Each 是每个测试方法都跑一次。如果你的测试类里有 10 个测试方法BeforeAll只执行 1 次BeforeEach执行 10 次。3.2 通过实际输出理解执行顺序我建议你自己动手写一个类验证一下执行顺序这样比背任何文档都管用import org.junit.jupiter.api.*; class LifecycleTest { BeforeAll static void initAll() { System.out.println(BeforeAll: 整个测试类开始前执行一次); } AfterAll static void tearDownAll() { System.out.println(AfterAll: 整个测试类结束后执行一次); } BeforeEach void init() { System.out.println(BeforeEach: 每个测试方法前执行); } AfterEach void tearDown() { System.out.println(AfterEach: 每个测试方法后执行); } Test void testOne() { System.out.println(执行测试方法 one); } Test void testTwo() { System.out.println(执行测试方法 two); } }运行结果会是这样BeforeAll: 整个测试类开始前执行一次 BeforeEach: 每个测试方法前执行 执行测试方法 one AfterEach: 每个测试方法后执行 BeforeEach: 每个测试方法前执行 执行测试方法 two AfterEach: 每个测试方法后执行 AfterAll: 整个测试类结束后执行一次不过有个前提就是 IDEA 默认的执行顺序可能按照方法名字符串来排testOne会先于testTwo执行。如果你在真实环境中发现顺序不稳定别慌测试方法之间本来就不应该依赖执行顺序。3.3 为什么测试之间必须完全隔离理解生命周期之后接下来一个重要概念就是测试隔离。JUnit 5 默认对每个测试方法都会创建一个新的测试类实例这意味着你在testOne里给成员变量赋的值在testTwo里是看不到的。这种设计是故意的——要保证每个测试方法都是独立运行的互不干扰。来一个反例让大家感受一下class BadTest { private int count 0; Test void test1() { count count 1; assertEquals(1, count); } Test void test2() { count count 1; assertEquals(1, count); } }因为count是从初始值 0 开始的两个测试方法各自都是在自己的实例上运算所以test1和test2都能通过。这就是 JUnit 5 默认PER_METHOD生命周期带来的好处。如果这是一个static int count两个测试就会共享这个变量那test1执行完后count变成 1test2执行时再1就变成 2断言assertEquals(1, count)就会挂掉。这就是典型的静态状态污染后面我会专门讲这个坑。但有些场景下我们希望BeforeAll不是静态方法比如想在初始化时访问实例变量那可以给测试类加上TestInstance(TestInstance.Lifecycle.PER_CLASS)让整个测试类只创建一个实例所有测试方法共享这个实例。这样BeforeAll和AfterAll就不必是静态方法了。但除非有明确的理由否则不建议新手这么做默认的每个方法一个实例能避免很多诡异的问题。4. 断言不是装饰品Assertions API的正确打开方式4.1 assertEquals 的参数顺序陷阱在 JUnit 5 里assertEquals最常用的重载是assertEquals(expected, actual)第一个参数是期望值第二个参数是实际值。新手经常写反变成assertEquals(calculator.add(2, 3), 5)。如果你把实际值放在前面、期望值放在后面代码是能跑的因为这个方法的两个参数类型一样编译器不会报错但一旦失败JUnit 打印的提示信息就会让人摸不着头脑Expected :实际计算出来的值 Actual :你写死的期望值等于把期望和实际完全搞反了排查问题的时候要多转一道弯。所以从第一天起就养成正确的参数顺序这对调试体验的影响非常大。4.2 用 assertThrows 验证异常行为除了验证正常的返回值我们经常还需要验证“这个方法在特定输入下应该抛异常”。很多老代码里是这么写的Test void divideByZeroShouldThrow() { try { calculator.divide(1, 0); fail(这里不应该执行到); } catch (ArithmeticException e) { // 捕获到异常测试通过 } }这种写法的问题在于如果你忘了调用fail()当异常没有抛出来时测试也会通过但这并不是你想要的结果。JUnit 5 提供了更优雅的assertThrowsimport static org.junit.jupiter.api.Assertions.assertThrows; Test void divideByZeroShouldThrow() { ArithmeticException exception assertThrows(ArithmeticException.class, () - calculator.divide(1, 0)); assertEquals(/ by zero, exception.getMessage()); }assertThrows会执行你传入的 Lambda 表达式如果表达式抛出了指定类型的异常测试通过并且返回这个异常对象你可以继续对异常内部的信息做断言如果没有抛出异常或者抛出的类型不匹配测试失败并给出明确提示。这是推荐的标准写法简洁、可读性强也避免了 try-catch 结构里容易漏写fail()的问题。4.3 超时断言与多重断言JUnit 5 提供了assertTimeout它可以验证一个操作是否在指定时间内完成import static org.junit.jupiter.api.Assertions.assertTimeout; import java.time.Duration; Test void shouldFinishWithinOneSecond() { assertTimeout(Duration.ofSeconds(1), () - { // 需要验证执行时间的业务逻辑 }); }这个功能适合用来验证算法性能是否符合预期或者防止代码出现死循环。但要注意assertTimeout等待的是一个线程在指定时间内完成在测试失败时其他代码可能还在后台继续运行容易造成测试之间的干扰。如果你只是想快速判断代码是否超时可以用assertTimeoutPreemptively它会强制中断超时的执行线程。但后者在线程本地变量、静态变量等场景下可能带来意料之外的问题建议优先用assertTimeout。还有一个很实用的断言是assertAll。它允许你在一个测试方法里同时执行多个断言即使前面某个断言失败了后面的断言也会继续执行最终把所有失败信息一次性汇总出来Test void userInfoShouldBeCorrect() { User user new User(张三, 25, zhangsanexample.com); assertAll(用户信息校验, () - assertEquals(张三, user.getName()), () - assertEquals(25, user.getAge()), () - assertEquals(zhangsanexample.com, user.getEmail()) ); }没有assertAll的时候一旦第一个断言失败后面的断言根本不会执行你只能修好一个问题重新跑一次再发现下一个问题。用assertAll可以一次看到所有失败项效率会高很多。4.4 失败消息怎么写才有价值assertEquals还支持传入第三个参数自定义失败消息。很多新手忽略了这个参数导致测试挂掉时只能看到一堆数字完全不知道为什么会失败、是哪个场景下失败。我个人的习惯是在涉及计算逻辑、复杂业务规则的时候一定要加上上下文信息。Test void discountShouldBeAppliedCorrectly() { double originalPrice 100.0; double discount 0.8; double expected 80.0; double actual priceCalculator.applyDiscount(originalPrice, discount); assertEquals(expected, actual, () - 计算折扣出错原价 originalPrice , 折扣 discount); }注意到这里我用了 Lambda 表达式() - ...而不是直接传字符串因为直接传字符串的话JVM 在每次断言时都会执行字符串拼接即使测试是通过的、根本用不到这个消息也要白白付出拼接的代价。用 Lambda 表达式可以做到惰性加载只有断言失败时才会真正执行字符串拼接。这个性能优化在测试量大的时候是有意义的。5. 参数化测试一份逻辑多组数据彻底告别复制粘贴5.1 没有参数化测试时你只能复制粘贴假设你要验证一个判断年份是否为闰年的方法正常的年份、世纪年、非世纪年、边界年份你至少得准备四五个测试数据。没有参数化测试的时候你不能在一个Test方法里塞多个用例因为那样第一个断言失败后面就不执行了你分不清到底是哪个用例出了问题。于是你只能复制好几个几乎一模一样的测试方法Test void isLeapYear_case1() { assertTrue(DateUtil.isLeapYear(2000)); } Test void isLeapYear_case2() { assertFalse(DateUtil.isLeapYear(1900)); }这种代码写起来烦维护起来更烦。哪天方法签名改了你要挨个去改所有复制出来的测试方法。JUnit 5 内置参数化测试就是专门用来解决这个问题的。5.2 三种常用数据源ParameterizedTest注解配合数据源注解可以让同一个测试逻辑跑多组数据。最常用的有三种ValueSource适合传单组简单数据比如基本类型和字符串ParameterizedTest ValueSource(ints {1, 2, 3, 4}) void testIntValues(int number) { assertTrue(number 0); }CsvSource适合传多组数据每个参数之间用逗号分隔可以传 null 和空字符串ParameterizedTest CsvSource({ 2000, true, 1900, false, 2024, true, 2023, false }) void leapYearShouldReturnExpectedResult(int year, boolean expected) { assertEquals(expected, DateUtil.isLeapYear(year)); }MethodSource最强大适合传复杂对象、集合、Stream以及参数个数不确定的场景。方法必须返回Stream、Iterable、Iterator或参数数组而且必须是非 private 的静态方法ParameterizedTest MethodSource(userProvider) void testUserValidation(User user, boolean expectedValid) { assertEquals(expectedValid, userValidator.isValid(user)); } static StreamArguments userProvider() { return Stream.of( Arguments.of(new User(张三, 25), true), Arguments.of(new User(, 25), false), Arguments.of(new User(张三, -1), false) ); }还有一个非常有用的参数ParameterizedTest(name {index} year{0}, expected{1})。这样你在测试报告里就能直接看到是哪一组参数失败了而不是只有一行模糊的testLeapYear失败信息。{0}代表第一个参数{1}代表第二个参数{index}是当前数据行的索引。5.3 参数化测试的命名与可读性用参数化测试还有一个额外的好处测试方法只需要写一个但从测试报告的角度看它会产生多条测试用例记录。配合自定义命名模板你能清楚地看到每条测试用例覆盖了什么场景这比在一个方法里用 for 循环断言要清晰得多。但这里有个很容易踩的坑参数化测试方法不能是 private数据源方法如果是MethodSource指定的也必须是 static 方法除非测试类标注了TestInstance(PER_CLASS)。有些新手把数据源方法写成实例方法编译就报错。如果是在 Java 8 以前的环境里还需要额外依赖junit-jupiter-params但我们是直接用junit-jupiter聚合依赖所以这一层的依赖问题已经帮大家省掉了。6. 动态测试与嵌套测试JUnit 5的进阶玩法6.1 Nested 让测试结构跟着业务逻辑走当你的业务类方法比较多或者一个业务的场景特别复杂时把所有测试方法平铺在一个类里会显得臃肿且难以阅读。JUnit 5 的Nested注解允许在一个测试类中创建内部测试类把相关的测试分组组织起来。比如我们有一个订单服务类包含下单、取消订单、查询订单等方法测试类可以这样组织class OrderServiceTest { OrderService orderService; BeforeEach void setUp() { orderService new OrderService(); } Nested class CreateOrder { Test void shouldCreateOrderWhenUserValid() { // ...下单正常逻辑 } Test void shouldThrowExceptionWhenUserInvalid() { // ...用户无效场景 } } Nested class CancelOrder { Test void shouldCancelOrderWhenStatusPending() { // ...待支付状态可取消 } Test void shouldNotCancelOrderWhenStatusShipped() { // ...已发货状态不可取消 } } }这样组织测试的好处是跑起来的时候 IDEA 的测试报告会显示清晰的层级结构你和团队其他成员一眼就能看出每个模块对应的测试覆盖情况。注意Nested内部类必须是非静态内部类而且 JUnit 5 中不加public修饰符也能正常工作。6.2 TestFactory 在运行时生成测试用例TestFactory可以让你在运行时动态生成测试用例返回值可以是DynamicTest的集合、流或数组。它特别适合那些输入数据直到运行时才能确定的场景或者你想在测试中对一批数据执行同一套逻辑并生成独立测试报告的场合。TestFactory StreamDynamicTest dynamicTestsForLeapYear() { ListInteger years Arrays.asList(2000, 1900, 2024, 2023); ListBoolean expectedResults Arrays.asList(true, false, true, false); return IntStream.range(0, years.size()) .mapToObj(i - dynamicTest( 验证年份 years.get(i) 是否为闰年, () - assertEquals(expectedResults.get(i), DateUtil.isLeapYear(years.get(i))) )); }运行这段代码测试报告里会显示四条独立的动态测试用例每条都有自己的名字。注意TestFactory方法本身不能是Test方法它只能标识在工厂方法上。这个方法很多新手容易混乱其实你只要记住一句话Test是提前把测试逻辑定死TestFactory是运行时由代码生成测试用例。7. 真实项目中容易踩的坑与解决办法7.1 静态可变状态的污染这是我在实际项目里见过最多的问题。新人在写测试时为了省事用静态变量保存状态结果测试之间就会通过静态变量互相影响。比如一个测试修改了静态配置另一个测试读到了被篡改的配置直接失败而且报错信息让你完全摸不着头脑。解决办法很简单测试代码里尽量避免使用可变的静态变量如果一定要用在BeforeEach或AfterEach里做重置。还有BeforeAll里做初始化时要特别注意这个初始化只执行一次对整个测试类里的所有方法都有效如果某个测试方法会修改这个静态状态后面的测试就会中招。最好的办法是让BeforeAll只初始化那些真正全局共享且不会被修改的资源。7.2 随机数据导致偶发失败有的同学在写测试时喜欢用Random生成测试数据结果某个测试方法偶尔会失败但不是每次都能复现。这种问题最耗时间因为你无法确定到底是什么数据触发了问题。我的经验是测试数据必须可复现。如果要用随机数一定要指定固定的随机种子Test void sortShouldHandleRandomInput() { Random random new Random(42); // 固定种子 int[] array new int[100]; for (int i 0; i array.length; i) { array[i] random.nextInt(); } // 断言排序结果 }固定种子后每次运行生成的随机序列完全相同失败了也能稳定复现。这条原则也适用于其他涉及时间、并发等不确定因素的测试。7.3 只测“快乐路径”不测边界条件很多初学者写测试时习惯性地只测试“正常情况”——输入合法数据得到预期结果。这种习惯很危险因为代码真正出问题往往是在边界空字符串、null、0、负数、极大值、浮点精度、集合为空、字符串超长。每次写完测试我都建议你专门停下来想一想这个方法在处理边界输入时会不会出问题然后把这些边界用例补进去。判断一个字段是否为空、一个数字是否在合法范围内这类校验逻辑特别适合参数化测试。把正常情况和边界情况全部列进去一份测试逻辑覆盖全部既省代码又能直观看到测试覆盖程度。7.4 测试代码也是要维护的代码很多项目里的测试代码到最后会变得一团糟原因在于大家把测试代码当成“二等公民”觉得它只要能跑就行。但测试代码是需要长期演进、经常运行的它的可读性直接影响整个团队的维护效率。我个人的习惯是测试方法名尽量做到“看图说话”一看就知道它在验证什么。国内团队用中文方法名也挺常见JDK 也支持中文标识符这个可以根据团队约定来。更推荐的做法是方法名描述行为比如shouldThrowExceptionWhenOrderStatusIsShipped。像test1、test2这种毫无信息量的方法名过了一个月你再回头看根本不知道它当时在测什么定位问题会非常痛苦。还可以在测试方法内部用注释把场景分为三段给定条件Given、执行操作When、验证结果Then。这个习惯能让你在写测试时思路更清晰也让读代码的人很容易理解测试的意图。写在最后的实操心得JUnit 上手其实很快真正的门槛是养成“先想测试、再写实现”或者“写完实现立刻补测试”的习惯。我在教 JavaSE 的时候一直跟学生强调一个观点代码跑通不代表正确正确性要靠测试来证明。你的时间不应该花在反反复复地打印输出、肉眼比对结果上而应该花在描述清楚“这段代码应该怎么表现才算正确”上——这个描述就是测试。给新手一个具体可落地的建议不要追求 100% 覆盖率那个指标在真实项目里意义不大。先把核心业务逻辑、边界条件、异常场景覆盖住比盲目堆一万个无意义的断言有用得多。从一个简单的工具类开始比如日期工具、金额计算、字符串处理每写一个方法就顺手补几个测试坚持一个月你一定能明显感觉到改代码时敢下手了重构时心里有底了。这种安全感的建立比会背多少 API 都重要。