当前位置：首页 > news >正文

39_Java单元测试JUnit入门

news 2026/6/16 13:22:00

Java单元测试JUnit入门

文章目录

Java单元测试JUnit入门
- 前言
- 一、环境准备与第一个测试
- 二、JUnit常用注解
- 三、断言（Assertions）
- 四、测试套件（Test Suite）
- 五、参数化测试
- 六、Mock简介
- 总结
- ✅ 亮点总结
- 适用场景
- 扩展方向

前言

“这段代码没问题，不用测试”——这是软件工程中最危险的自负。一个bug在开发阶段被发现和在生产环境被用户发现，修复成本可能相差百倍。单元测试就是开发阶段最有效的质量保障手段，而JUnit是Java生态中最主流的单元测试框架。本文将从零开始，带你掌握JUnit的核心用法。

测试的ROI：很多开发者抗拒写单元测试的理由是"浪费时间"。但实际上，调试一个没有测试覆盖的bug所花的时间，通常是写测试的3-5倍——因为你需要在脑海中重新构建代码的上下文，还要手动构造测试数据、模拟各种边界条件。更重要的是，有单元测试保护的代码，你可以放心重构而不怕引入回归bug。单元测试就像一份"代码的行为说明书"，几个月后你回来看代码，跑一遍测试就知道各方法期望的输入输出是什么。在实际面试中，是否有写测试的习惯也是区分初中级和高级工程师的重要标尺。

一、环境准备与第一个测试

在Maven项目中添加JUnit依赖（以JUnit 4为例，JUnit 5时代码会更现代）：

<dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.13.2</version><scope>test</scope></dependency>

编写被测试的类：

// src/main/java/com/example/Calculator.javapublicclassCalculator{publicintadd(inta,intb){returna+b;}publicintdivide(inta,intb){if(b==0){thrownewIllegalArgumentException("除数不能为0");}returna/b;}publicintmultiply(inta,intb){returna*b;}}

编写测试类（测试类命名规范：被测类名+Test）：

// src/test/java/com/example/CalculatorTest.javaimportorg.junit.Test;importstaticorg.junit.Assert.*;publicclassCalculatorTest{@TestpublicvoidtestAdd(){Calculatorcalc=newCalculator();intresult=calc.add(2,3);assertEquals("2 + 3 应该等于 5",5,result);}@TestpublicvoidtestDivide(){Calculatorcalc=newCalculator();assertEquals(3,calc.divide(6,2));assertEquals(0,calc.divide(0,5));}@Test(expected=IllegalArgumentException.class)publicvoidtestDivideByZero(){Calculatorcalc=newCalculator();calc.divide(10,0);// 期望抛出异常}}

测试方法命名建议：test + 方法名 + 测试场景，如testDivideByZero。也可以使用Given-When-Then风格：givenTwoNumbers_whenAdd_thenReturnSum。

测试方法编写的基本原则——AAA模式：Arrange（准备测试数据）、Act（执行被测方法）、Assert（断言结果）。例如上面的testAdd：先Arrange创建Calculator对象，再Act调用calc.add(2,3)，最后Assert断言assertEquals(5, result)。清晰的AAA结构让测试一目了然，评审者能快速理解测试意图。注意AAA并不是说每个测试只能有一个Act——有时需要连续调用多个方法来完成一个业务场景——但核心是"准备-执行-验证"的清晰分工。

二、JUnit常用注解

JUnit提供了丰富的注解来控制测试的生命周期和行为：

importorg.junit.*;importstaticorg.junit.Assert.*;publicclassLifecycleTest{// 在所有测试方法之前执行一次（必须是static）@BeforeClasspublicstaticvoidsetUpBeforeClass(){System.out.println("[@BeforeClass] 整个测试类初始化一次");// 典型用途：建立数据库连接、加载配置文件}// 在所有测试方法之后执行一次（必须是static）@AfterClasspublicstaticvoidtearDownAfterClass(){System.out.println("[@AfterClass] 整个测试类清理一次");// 典型用途：关闭数据库连接}// 在每个@Test方法之前执行@BeforepublicvoidsetUp(){System.out.println(" [@Before] 每个测试方法前执行");// 典型用途：初始化测试数据}// 在每个@Test方法之后执行@AfterpublicvoidtearDown(){System.out.println(" [@After] 每个测试方法后执行");// 典型用途：清理测试数据}@TestpublicvoidtestMethod1(){System.out.println(" testMethod1");assertTrue(true);}@TestpublicvoidtestMethod2(){System.out.println(" testMethod2");assertEquals(4,2+2);}// 忽略此测试（暂不执行）@Ignore("等待需求确认后实现")@TestpublicvoidtestNotReady(){// 这个测试暂时跳过}// 超时测试（单位：毫秒）@Test(timeout=1000)publicvoidtestTimeout(){// 如果超过1秒仍未完成，判定为失败try{Thread.sleep(500);}catch(InterruptedExceptione){e.printStackTrace();}}}

输出示例：

[@BeforeClass] 整个测试类初始化一次 [@Before] 每个测试方法前执行 testMethod1 [@After] 每个测试方法后执行 [@Before] 每个测试方法前执行 testMethod2 [@After] 每个测试方法后执行 [@AfterClass] 整个测试类清理一次

三、断言（Assertions）

断言是测试的核心，JUnit提供了丰富的断言方法。理解各种断言方法的适用场景，能让你的测试更精准、失败信息更清晰。

典型错误用法：用assertTrue(condition)替代所有断言。比如assertTrue(a == b)——如果失败，你只能看到"expected true but was false"，但看不到a和b的实际值。应该用assertEquals(expected, actual)——失败时会打印"expected 5 but was 3"，直接定位问题。同理，不要用assertTrue(list.contains(x))，而要用专门的集合断言或assertThat。

importorg.junit.Test;importstaticorg.junit.Assert.*;publicclassAssertionDemo{@TestpublicvoidtestAssertions(){// 等值断言assertEquals("字符串应相等","hello","hello");assertEquals("浮点数有精度误差",3.14,3.14159,0.01);// 第三个参数是误差范围// 真假断言assertTrue("条件应为真",5>3);assertFalse("条件应为假",1>2);// 空值断言Stringstr=null;assertNull("应为null",str);assertNotNull("不应为null","hello");// 相同引用断言（== 而非 equals）Strings1="abc";Strings2=s1;assertSame(s1,s2);// 数组断言int[]expected={1,2,3};int[]actual={1,2,3};assertArrayEquals(expected,actual);}}

经验法则：每个测试方法只测一个行为，并使用有意义的断言消息（第一个参数），这样测试失败时能快速定位问题。

一条测试多个断言还是多个测试？原则是：测试同一个"行为"的不同方面可以放多个断言；测试不同"行为"必须分开。比如测试divide方法，testDivideNormal可以同时断言divide(6,2)==3和divide(0,5)==0，因为这都是在测"正常除法"；但testDivideByZero必须单独写一个测试方法，因为它在测"异常路径"。混在一起的话，第一个断言失败后，后面的断言就不会执行了，你无法知道后面的行为是否也出问题了。

四、测试套件（Test Suite）

当测试类越来越多时，可以用测试套件将它们组合在一起批量执行：

importorg.junit.runner.RunWith;importorg.junit.runners.Suite;@RunWith(Suite.class)@Suite.SuiteClasses({CalculatorTest.class,LifecycleTest.class,AssertionDemo.class})publicclassAllTests{// 此类为空，仅作为套件的容器// 运行此类即可执行所有指定的测试类}

多个套件还可以嵌套组合：

@RunWith(Suite.class)@Suite.SuiteClasses({BusinessTestSuite.class,UtilTestSuite.class})publicclassFullTestSuite{}

五、参数化测试

当需要测试同一逻辑在不同输入下的表现时，参数化测试可以避免写大量相似的测试方法：

importorg.junit.Test;importorg.junit.runner.RunWith;importorg.junit.runners.Parameterized;importjava.util.Arrays;importjava.util.Collection;importstaticorg.junit.Assert.assertEquals;@RunWith(Parameterized.class)publicclassCalculatorParameterizedTest{privateinta;privateintb;privateintexpected;// 构造器接收参数publicCalculatorParameterizedTest(inta,intb,intexpected){this.a=a;this.b=b;this.expected=expected;}// 提供参数数据的方法@Parameterized.Parameters(name="{index}: {0} + {1} = {2}")publicstaticCollection<Object[]>data(){returnArrays.asList(newObject[][]{{1,1,2},{2,3,5},{0,0,0},{-1,1,0},{100,200,300}});}@TestpublicvoidtestAdd(){Calculatorcalc=newCalculator();assertEquals(expected,calc.add(a,b));}}

六、Mock简介

单元测试讲究隔离。当被测试的类依赖数据库或外部服务时，我们用Mock对象来模拟这些依赖。

为什么要Mock？单元测试的目标是验证被测类自身的逻辑，而不是它所依赖的外部系统。如果你的UserService里调用了PaymentGateway，而PaymentGateway又连接了真实的支付接口，那么：

测试会变慢（网络延迟）
测试不稳定（支付接口可能挂了）
会产生副作用（真的扣了钱）
无法测试边缘场景（如支付接口返回超时、返回异常）

Mock对象让你完全掌控依赖的行为，可以模拟"支付成功"“支付失败”"支付超时"等各种场景，而不依赖任何外部系统。

// 需要引入 Mockito 依赖// 业务类：依赖外部服务classOrderService{privatePaymentGatewaypaymentGateway;publicOrderService(PaymentGatewaypaymentGateway){this.paymentGateway=paymentGateway;}publicStringplaceOrder(doubleamount){if(paymentGateway.process(amount)){return"订单成功";}return"支付失败";}}interfacePaymentGateway{booleanprocess(doubleamount);}// 手动MockclassMockPaymentGatewayimplementsPaymentGateway{privatebooleanshouldSucceed;publicMockPaymentGateway(booleanshouldSucceed){this.shouldSucceed=shouldSucceed;}@Overridepublicbooleanprocess(doubleamount){returnshouldSucceed;}}// 测试@TestpublicvoidtestPlaceOrderSuccess(){PaymentGatewaymockGateway=newMockPaymentGateway(true);OrderServiceservice=newOrderService(mockGateway);assertEquals("订单成功",service.placeOrder(100.0));}@TestpublicvoidtestPlaceOrderFailure(){PaymentGatewaymockGateway=newMockPaymentGateway(false);OrderServiceservice=newOrderService(mockGateway);assertEquals("支付失败",service.placeOrder(100.0));}

更推荐使用Mockito框架进行Mock：

importstaticorg.mockito.Mockito.*;@TestpublicvoidtestWithMockito(){// 创建Mock对象PaymentGatewaygateway=mock(PaymentGateway.class);// 设定行为when(gateway.process(anyDouble())).thenReturn(true);OrderServiceservice=newOrderService(gateway);Stringresult=service.placeOrder(50.0);assertEquals("订单成功",result);// 验证方法被调用了verify(gateway).process(50.0);}

总结

单元测试不是负担，而是开发者的安全网。JUnit的核心要素包括：@Test注解标记测试方法、断言（Assert）验证结果、@Before/@After管理测试生命周期、测试套件批量执行。对于外部依赖，使用Mock对象来隔离测试。

测试覆盖率不是目的，有意义的测试才是。养成"写代码前先想测试"的习惯，你的代码质量将会有质的飞跃。

TDD入门：测试驱动开发（Test-Driven Development）的核心理念是"先写测试，再写实现"。三部曲是：Red（写一个失败的测试）→ Green（写最少代码让测试通过）→ Refactor（重构代码，测试仍然通过）。TDD最大的好处不是"先写测试"本身，而是它迫使你先思考"这个类的接口应该是什么样的"“边界条件有哪些”“什么算成功什么算失败”——这些思考反过来会让你的API设计更合理。即使你不完全采纳TDD，在写复杂业务逻辑前先列一份测试场景清单，也是极好的实践。