JUnit4单元测试实战：从核心注解到Mockito依赖隔离完整指南

1. 项目概述：为什么单元测试是开发者的“安全网”？

在软件开发的日常里，我们常常会遇到这样的场景：你信心满满地修改了一个看似无关紧要的公共方法，结果上线后，一个你从未想过的、八竿子打不着的功能模块突然崩溃了。排查问题花了大半天，最后发现是那个“无关紧要”的方法里，一个边界条件判断被你不小心改动了。这种“牵一发而动全身”的痛，相信很多开发者都经历过。而单元测试，就是用来抵御这种风险、为你的代码质量兜底的第一道，也是最重要的一道“安全网”。

JUnit，作为Java领域事实上的单元测试标准框架，其重要性不言而喻。而JUnit4，虽然现在JUnit5已经普及，但它依然是大量遗留项目和许多开发者入门单元测试的“必经之路”。理解JUnit4，不仅是掌握一个工具，更是理解单元测试的核心思想：隔离、验证、自动化。所谓“实战详解与实例解析”，就是要跳出官方文档的条条框框，从一个实际开发者的角度，去拆解如何用JUnit4写出有效、可维护、能真正发现问题的测试代码，而不是为了凑覆盖率而写的“摆设”。

这篇文章，我会结合我过去在多个项目中推行单元测试的经验，从最基础的注解使用，到复杂的依赖隔离（Mock），再到测试代码的组织与优化，用大量真实的代码示例，带你走一遍完整的JUnit4实战流程。无论你是刚接触单元测试的新手，还是想优化现有测试套件的老手，都能从中找到可以直接“抄作业”的实用技巧和避坑指南。

2. JUnit4核心注解与生命周期深度拆解

很多教程一上来就讲@Test，这没错，但如果不理解JUnit4执行测试方法的完整生命周期，你很容易写出一些看似能跑通，但实际上存在隐患的测试。JUnit4的魔力，很大程度上就藏在几个核心注解和它们的执行顺序里。

2.1 四大金刚：@Test, @Before, @After, @BeforeClass/@AfterClass

@Test：这是测试方法的标志。但一个常见的误区是，认为@Test方法里什么都能写。实际上，一个良好的单元测试方法应该遵循“3A”原则：准备（Arrange）、执行（Act）、断言（Assert）。先准备测试数据和预期结果，再调用被测方法，最后验证实际结果是否符合预期。

@Test public void testAdd() { // Arrange: 准备 Calculator calculator = new Calculator(); int a = 5; int b = 3; int expected = 8; // Act: 执行 int actual = calculator.add(a, b); // Assert: 断言 assertEquals("加法计算错误", expected, actual); }

@Before和@After：这两个注解的方法会在每个@Test方法执行之前和之后运行。它们是用来做测试的“准备”和“清理”工作的绝佳位置。

public class UserServiceTest { private UserService userService; private DatabaseConnection mockConnection; // 假设的依赖 @Before public void setUp() { // 每个测试方法前，都新建一个干净的UserService实例 mockConnection = Mockito.mock(DatabaseConnection.class); userService = new UserService(mockConnection); System.out.println("setUp: 准备测试环境"); } @After public void tearDown() { // 每个测试方法后，进行清理，如关闭临时文件、重置静态变量等 userService = null; System.out.println("tearDown: 清理测试环境"); } @Test public void testMethod1() { /* ... */ } @Test public void testMethod2() { /* ... */ } }

运行testMethod1和testMethod2，你会看到setUp和tearDown各执行了两次。这确保了测试之间的隔离性，一个测试的失败不会污染另一个测试的环境。

@BeforeClass和@AfterClass：这两个注解的方法是静态的（static），它们在整个测试类所有测试开始前和所有测试结束后，各执行一次。通常用于执行非常耗资源的初始化，比如建立数据库连接池、加载大型配置文件。

public class ExpensiveResourceTest { private static DataSource dataSource; @BeforeClass public static void setUpClass() { // 模拟一个耗时的资源初始化，比如连接池 dataSource = createHikariDataSource(); System.out.println("setUpClass: 初始化昂贵资源，只执行一次"); } @AfterClass public static void tearDownClass() { if (dataSource != null) { dataSource.close(); } System.out.println("tearDownClass: 关闭昂贵资源，只执行一次"); } @Test public void testQuery1() { // 使用 dataSource System.out.println("testQuery1 执行"); } @Test public void testQuery2() { // 使用 dataSource System.out.println("testQuery2 执行"); } }

一个非常重要的实操心得：绝对不要在@Before或@BeforeClass里初始化那些会被测试方法修改状态的对象（尤其是静态对象）。比如，你在@Before里初始化了一个List并添加了一些数据，然后在某个@Test方法里清空了这个List。那么，下一个@Test方法运行时，@Before会再次执行，重新初始化List吗？会！但这意味着前一个测试对List的修改影响了后一个测试的初始状态吗？从逻辑上看没有，因为@Before重新创建了对象。但关键在于，这可能会掩盖一些并发或状态残留的问题。最安全的做法是，在@Before里只做最小化、无状态的准备工作，比如创建对象实例、Mock依赖。测试数据最好在@Test方法内部“按需创建”。

2.2 被忽视的利器：@Ignore 与 超时、异常测试

@Ignore：这个注解太有用了，但经常被低估。当一个测试暂时失败（比如依赖的外部接口挂了），或者你正在重构代码，测试还没适配好时，与其注释掉测试方法（这会导致你彻底忘记它），不如加上@Ignore并附上原因。这样测试报告会明确显示有多少测试被忽略了，提醒你后续处理。

@Test @Ignore("待第三方服务恢复后启用 - 张三 2023-10-27") public void testExternalApiCall() { // 调用一个暂时不可用的外部API }

超时测试@Test(timeout=毫秒)：用于检测方法执行是否超时。这对于测试那些可能有死循环、或依赖网络请求性能的方法非常有用。

@Test(timeout = 1000) // 1秒内必须执行完 public void testPerformanceCriticalMethod() { // 执行一个性能关键的方法 someService.processLargeData(); }

注意：超时测试的结果可能受运行环境（如CI服务器负载）影响，所以超时时间要设置得合理，不要太极限。

异常测试@Test(expected=异常类.class)：用于验证方法在特定输入下是否会抛出预期的异常。

@Test(expected = IllegalArgumentException.class) public void testDivideByZero() { Calculator calculator = new Calculator(); calculator.divide(10, 0); // 预期这里会抛出IllegalArgumentException }

踩过的坑：expected属性只能验证异常类型，无法验证异常信息（message）。如果你需要验证异常的具体信息，或者异常是在一段代码块中抛出的（而不是测试方法直接抛出），更推荐使用JUnit4的ExpectedException规则（Rule）或者try-catch-assert模式。

3. 断言的艺术：从assertEquals到Hamcrest

断言是测试的灵魂，它决定了测试的“检查点”是否精准。JUnit4自带的org.junit.Assert类提供了很多基础的断言方法，但用好它们需要技巧。

3.1 基础断言：不仅仅是assertEquals

assertEquals(expected, actual)是最常用的，但要注意参数顺序。习惯上把期望值放前面，实际值放后面，这样断言失败时的错误信息更易读。对于浮点数比较，务必使用assertEquals(double expected, double actual, double delta)，其中delta是允许的误差范围。

@Test public void testFloatCalculation() { double result = 10.0 / 3.0; // 错误写法：assertEquals(3.333, result); // 很可能失败，因为浮点数精度问题 // 正确写法： assertEquals(3.333, result, 0.001); // 允许0.001的误差 }

assertTrue和assertFalse用于布尔条件。assertNull和assertNotNull用于对象空值判断。assertSame和assertNotSame用于判断是否是同一个对象引用（==），而assertEquals判断的是equals()。

一个关键技巧：总是为断言提供有意义的失败信息（message参数）。当测试失败时，一个清晰的错误信息能帮你快速定位问题。

@Test public void testUserCreation() { User user = userService.createUser("testUser"); // 不好的写法： assertNotNull(user); // 好的写法： assertNotNull("创建用户后返回的对象不应为null", user); assertEquals("新创建用户的用户名应一致", "testUser", user.getUsername()); }

3.2 进阶选择：Hamcrest匹配器

JUnit4自带的断言有时在表达复杂条件时显得笨拙。Hamcrest库通过提供一组可读性极高的“匹配器（Matcher）”，让断言语句读起来像自然语言。你需要额外引入hamcrest-library依赖。

import static org.hamcrest.MatcherAssert.assertThat; import static org.hamcrest.Matchers.*; @Test public void testWithHamcrest() { List<String> result = someService.getItems(); // 断言集合包含特定元素 assertThat(result, hasItem("expectedItem")); // 断言集合大小 assertThat(result, hasSize(5)); // 断言集合包含多个元素（顺序无关） assertThat(result, containsInAnyOrder("a", "b", "c")); // 断言对象多个属性 User user = getUser(); assertThat(user, allOf( hasProperty("name", is("张三")), hasProperty("age", greaterThan(18)) )); // 断言数字范围 int score = getScore(); assertThat(score, allOf(greaterThanOrEqualTo(0), lessThanOrEqualTo(100))); }

Hamcrest的强大在于其组合能力，你可以用allOf（与）、anyOf（或）、not（非）来组合复杂的断言条件，代码的意图一目了然。我个人的体会是，在团队项目中推广Hamcrest，能显著提升测试代码的可读性和可维护性。

4. 依赖隔离实战：当你的代码需要“朋友”

单元测试的核心是“单元”，意味着我们要把被测试的类或方法隔离出来，让它依赖的外部组件（数据库、网络服务、文件系统、其他复杂类）都变成可控的“演员”。这就是Mock（模拟）和Stub（桩）的概念。在JUnit4生态中，Mockito是进行依赖隔离的绝对主力。

4.1 Mockito核心：模拟行为与验证交互

假设我们有一个OrderService，它依赖PaymentGateway（支付网关）和InventoryService（库存服务）。

public class OrderService { private PaymentGateway paymentGateway; private InventoryService inventoryService; public OrderService(PaymentGateway paymentGateway, InventoryService inventoryService) { this.paymentGateway = paymentGateway; this.inventoryService = inventoryService; } public boolean placeOrder(Order order) { // 1. 检查库存 if (!inventoryService.isItemInStock(order.getItemId(), order.getQuantity())) { return false; } // 2. 尝试支付 boolean paymentSuccess = paymentGateway.charge(order.getTotalAmount(), order.getCreditCard()); if (!paymentSuccess) { return false; } // 3. 扣减库存 inventoryService.reduceStock(order.getItemId(), order.getQuantity()); return true; } }

我们要测试placeOrder方法，但绝不能真的去调用支付网关和库存数据库。这时就用Mockito。

import static org.mockito.Mockito.*; import org.junit.Test; import org.junit.runner.RunWith; import org.mockito.InjectMocks; import org.mockito.Mock; import org.mockito.junit.MockitoJUnitRunner; @RunWith(MockitoJUnitRunner.class) // 使用Mockito的JUnit运行器 public class OrderServiceTest { @Mock private PaymentGateway mockPaymentGateway; // 声明Mock对象 @Mock private InventoryService mockInventoryService; @InjectMocks private OrderService orderService; // Mockito会自动将上面的mock注入到这里 @Test public void testPlaceOrder_Success() { // Arrange Order testOrder = new Order("item123", 2, 100.0, "card_xxx"); // 设定Mock对象的行为：当调用isItemInStock时返回true when(mockInventoryService.isItemInStock("item123", 2)).thenReturn(true); // 设定Mock对象的行为：当调用charge时返回true when(mockPaymentGateway.charge(100.0, "card_xxx")).thenReturn(true); // Act boolean result = orderService.placeOrder(testOrder); // Assert assertTrue(result); // 验证交互：reduceStock方法被调用了一次，且参数是特定的 verify(mockInventoryService, times(1)).reduceStock("item123", 2); // 验证charge方法被调用了一次 verify(mockPaymentGateway, times(1)).charge(100.0, "card_xxx"); } @Test public void testPlaceOrder_OutOfStock() { // Arrange Order testOrder = new Order("item123", 2, 100.0, "card_xxx"); // 模拟库存不足 when(mockInventoryService.isItemInStock("item123", 2)).thenReturn(false); // Act boolean result = orderService.placeOrder(testOrder); // Assert assertFalse(result); // 验证：因为库存不足，后续的支付和扣库存都不应该发生 verify(mockPaymentGateway, never()).charge(anyDouble(), anyString()); verify(mockInventoryService, never()).reduceStock(anyString(), anyInt()); } }

关键点解析：

1. @RunWith(MockitoJUnitRunner.class)： 这是关键，它告诉JUnit使用Mockito的测试运行器，这样才能让@Mock和@InjectMocks注解生效。
2. @Mock： 创建一个Mock对象。这个对象的所有方法默认返回“空”值（0, false, null等）。
3. @InjectMocks： 创建被测类的真实实例，并自动将上面声明的@Mock对象注入进去（通过构造函数或setter方法）。
4. when(...).thenReturn(...)： 这是打桩（Stubbing），用于定义当Mock对象的某个方法以特定参数被调用时，应该返回什么值。这是为了给测试提供必要的输入。
5. verify(...)： 这是验证（Verification），用于检查在测试执行过程中，Mock对象的某个方法是否被调用、调用了几次、参数是什么。这是为了验证被测对象的行为是否符合预期。

4.2 高级Mock技巧与常见陷阱

参数匹配器（Argument Matchers）： 当你不关心具体的参数值，或者参数是复杂对象时，可以使用any(),anyString(),anyInt(),eq()等匹配器。

// 模拟：无论传入什么字符串，都返回true when(mockService.doSomething(anyString())).thenReturn(true); // 验证：方法被调用，且第一个参数是"abc"，第二个参数是任意整数 verify(mockService).doSomething(eq("abc"), anyInt());

注意：一旦在某个方法调用中使用了一个参数匹配器，那么该方法的所有参数都必须使用匹配器。不能混合使用具体值和匹配器（eq()除外，它本身就是匹配器）。

抛出异常： 可以模拟方法抛出异常。

when(mockFileService.readFile(anyString())).thenThrow(new IOException("File not found"));

验证调用顺序： 使用InOrder对象。

InOrder inOrder = inOrder(mockA, mockB); inOrder.verify(mockA).method1(); inOrder.verify(mockB).method2(); // 确保method1在method2之前被调用

一个巨大的坑：过度Mock。Mock是为了隔离不可控依赖。但如果你把被测类依赖的所有其他类都Mock了，甚至把同一个模块下的其他类也Mock了，那你的测试就变成了“在真空中测试”，失去了意义。单元测试应该聚焦于当前类的逻辑，Mock掉的是真正的外部依赖（如数据库、HTTP客户端、第三方SDK）。对于同一个模块内、共同完成一个业务逻辑的多个类，应该通过集成测试来覆盖。

5. 测试套件与参数化测试：提升测试效率

当项目变大，测试类越来越多，如何组织和管理它们？如何对同一个方法用多组不同数据进行测试？JUnit4提供了相应的工具。

5.1 测试套件（Test Suite）

测试套件允许你将多个测试类组合在一起运行。这在你想按模块或功能分组运行测试时非常有用。

import org.junit.runner.RunWith; import org.junit.runners.Suite; @RunWith(Suite.class) @Suite.SuiteClasses({ CalculatorTest.class, UserServiceTest.class, OrderServiceTest.class }) public class AllUnitTests { // 这个类本身是空的，只是一个套件的容器 }

运行AllUnitTests，就会依次运行CalculatorTest、UserServiceTest和OrderServiceTest中的所有测试方法。在IDE或Maven/Gradle中配置运行这个套件类即可。

5.2 参数化测试（Parameterized Tests）

如果你有一个方法，其逻辑需要针对多种不同的输入组合进行验证，写多个几乎相同的@Test方法非常冗余。参数化测试可以解决这个问题。

你需要使用@RunWith(Parameterized.class)，并提供一个返回数据集合的@Parameters方法。

import org.junit.Test; import org.junit.runner.RunWith; import org.junit.runners.Parameterized; import org.junit.runners.Parameterized.Parameters; import java.util.Arrays; import java.util.Collection; import static org.junit.Assert.assertEquals; @RunWith(Parameterized.class) public class FibonacciTest { // 这两个字段会被注入 private int input; private int expected; // 构造函数，参数顺序和@Parameters方法返回的集合中每个Object数组的顺序一致 public FibonacciTest(int input, int expected) { this.input = input; this.expected = expected; } // 提供测试数据 @Parameters(name = "{index}: fib({0}) = {1}") // 为每个测试用例生成易读的名字 public static Collection<Object[]> data() { return Arrays.asList(new Object[][] { { 0, 0 }, { 1, 1 }, { 2, 1 }, { 3, 2 }, { 4, 3 }, { 5, 5 }, { 6, 8 } }); } @Test public void testFibonacci() { Fibonacci fib = new Fibonacci(); assertEquals(expected, fib.compute(input)); } }

运行这个测试类，JUnit会为data()方法返回的每一组数据（如{0,0},{1,1}）都创建一个FibonacciTest实例，并运行一次testFibonacci()方法。测试报告里会清晰地显示7个测试用例。

实操心得：参数化测试非常适合测试纯函数（无副作用，输出只由输入决定）和包含复杂分支条件的方法。它能极大减少重复代码，让测试用例的输入和预期输出一目了然。但要注意，如果测试逻辑本身很复杂（比如需要为每组数据准备不同的Mock行为），参数化测试可能会让测试方法变得难以理解，这时或许拆分成多个独立的@Test方法更清晰。

6. 测试代码的组织与可维护性实践

写测试代码和写生产代码一样，需要良好的设计和规范。糟糕的测试代码会成为项目的负担，而不是资产。

6.1 命名规范：让人一眼看懂测试意图

测试方法的命名应该清晰地表达它在测试什么，以及在什么条件下。一个流行的约定是methodName_StateUnderTest_ExpectedBehavior。

• calculateTax_IncomeBelowThreshold_ReturnsZero
• placeOrder_ItemOutOfStock_ReturnsFalse
• saveUser_NullUsername_ThrowsIllegalArgumentException

即使不使用这么长的命名，也至少要像testPlaceOrderSuccess、testPlaceOrderOutOfStock这样，让人一眼就知道区别。

6.2 遵循单一职责原则（SRP）

一个@Test方法应该只测试一个特定的行为或场景。不要在一个测试方法里验证多个不相关的逻辑。如果某个方法有多个重要的执行路径（比如if-else的不同分支），应该为每个路径写一个单独的测试方法。

反面教材：

@Test public void testUserService() { // 测试创建用户 User u1 = service.createUser(...); assertNotNull(u1); // 测试查找用户 User u2 = service.findUser(...); assertEquals(u1, u2); // 测试删除用户 service.deleteUser(...); assertNull(service.findUser(...)); }

这个测试方法混合了创建、查找、删除三个操作。如果“查找”测试失败了，你很难定位是查找逻辑本身有问题，还是前面“创建”的步骤没成功。而且测试报告只会显示testUserService失败了，信息量很少。

6.3 使用“准备-执行-断言”（AAA）模式

前面提到过，这是组织测试方法结构的黄金法则。把准备数据的代码（Arrange）、调用被测方法的代码（Act）、验证结果的代码（Assert）清晰地分开，通常用空行隔开。这能让测试逻辑非常清晰。

@Test public void testApplyDiscount_EligibleCustomer_GetsDiscount() { // Arrange Customer customer = new Customer(true); // 合格客户 Order order = new Order(100.0); DiscountService service = new DiscountService(); // Act double finalPrice = service.applyDiscount(order, customer); // Assert assertEquals(90.0, finalPrice, 0.001); // 打9折 }

6.4 测试数据的构建：使用Builder或Helper方法

如果创建测试对象很复杂，不要在每个测试方法里重复一堆setXXX。可以：

1. 使用建造者模式（Builder Pattern）为你的领域对象创建测试专用的Builder。
2. 在测试类里创建私有的Helper方法来生成常用的测试对象。

public class TestDataHelper { public static Order createStandardOrder() { Order order = new Order(); order.setId(UUID.randomUUID().toString()); order.setAmount(100.0); order.setStatus(OrderStatus.PENDING); // ... 设置其他默认值 return order; } public static Order createOrderWithItem(String itemId, int quantity) { Order order = createStandardOrder(); order.addItem(new OrderItem(itemId, quantity)); return order; } }

这样，你的测试方法就会非常简洁：

@Test public void testSomething() { // Arrange Order testOrder = TestDataHelper.createOrderWithItem("ITM001", 2); // ... 其他准备和断言 }

6.5 保持测试的独立性与幂等性

每个测试都应该是独立的，不依赖于其他测试的运行顺序或结果。这也是为什么我们要在@Before中初始化，在@After中清理。同时，测试应该是幂等的，即运行一次和运行多次的结果应该一样。这意味着测试不能依赖外部可变状态（比如数据库里一条特定的记录），或者每次运行都要能自己创建并清理所需的环境。

7. 集成测试与Spring环境下的JUnit4

单元测试是基础，但有些逻辑涉及Spring容器、数据库事务等，需要启动一个轻量级的集成环境来测试。这时我们会用到Spring TestContext Framework。

7.1 配置Spring测试环境

你需要引入spring-test依赖，并使用@RunWith(SpringJUnit4ClassRunner.class)和@ContextConfiguration注解。

@RunWith(SpringJUnit4ClassRunner.class) // 指定Spring的测试运行器 @ContextConfiguration(classes = {TestConfig.class}) // 指定Spring配置类 public class UserServiceIntegrationTest { @Autowired private UserService userService; // 从Spring容器中注入真实的Bean @Autowired private DataSource dataSource; // 可以注入其他Bean，如数据源 @Test @Transactional // 使用事务，测试后自动回滚，不污染数据库 public void testCreateAndFindUser() { // Arrange User newUser = new User("integrationUser"); // Act User savedUser = userService.save(newUser); User foundUser = userService.findById(savedUser.getId()); // Assert assertNotNull(foundUser); assertEquals(savedUser.getUsername(), foundUser.getUsername()); // 由于有@Transactional，保存的数据在测试结束后会被回滚 } }

这里的TestConfig.class是一个专门用于测试的Spring配置类，它可能配置了一个内存数据库（如H2）和必要的基础设施。

7.2 使用@MockBean与@SpyBean

在集成测试中，你可能只想Mock掉其中的一两个外部依赖（比如一个调用远程API的EmailService），而其他部分（如数据库访问的Repository）使用真实的Bean。Spring Boot提供了@MockBean和@SpyBean注解。

@RunWith(SpringRunner.class) // Spring Boot 1.4+ 的简化写法，等价于SpringJUnit4ClassRunner @SpringBootTest // 加载完整的Spring Boot应用上下文（或指定类） public class OrderServiceIntegrationTest { @Autowired private OrderService orderService; // 真实的OrderService @MockBean private PaymentGateway paymentGateway; // Mock掉支付网关 @Autowired private OrderRepository orderRepository; // 使用真实的Repository操作内存数据库 @Test @Transactional public void testPlaceOrderIntegration_Success() { // Arrange Order order = new Order(...); orderRepository.save(order); // 先持久化到测试数据库 when(paymentGateway.charge(anyDouble(), anyString())).thenReturn(true); // Mock支付成功 // Act boolean result = orderService.placeOrder(order.getId()); // Assert assertTrue(result); Order updatedOrder = orderRepository.findById(order.getId()).orElse(null); assertNotNull(updatedOrder); assertEquals(OrderStatus.PAID, updatedOrder.getStatus()); // 验证状态已更新 verify(paymentGateway).charge(eq(order.getTotalAmount()), anyString()); } }

@MockBean会在Spring应用上下文中，用Mockito的Mock对象替换掉原有类型的Bean。这样，OrderService里注入的PaymentGateway就是被我们控制行为的Mock对象了，而OrderRepository和数据库交互的部分则是真实的。

重要提示：集成测试比单元测试慢得多，因为它们要启动Spring容器、连接数据库等。所以应该将集成测试和单元测试分开，通常单元测试放在src/test/java下的某个包（如unit），集成测试放在另一个包（如integration），并使用不同的Maven/Gradle profile或任务来分别运行。

8. 常见问题排查与性能优化实录

即使掌握了所有技术点，在实际编写和运行测试时，你依然会遇到各种各样的问题。这里记录一些我踩过的坑和解决方案。

8.1 测试失败排查清单

8.2 提升测试套件性能

1. 隔离慢测试： 将运行时间长的集成测试、端到端测试与快速的单元测试分开。可以使用JUnit Categories（分类）或不同的Maven模块/Gradle SourceSet。
2. 并行运行测试： 现代构建工具和IDE都支持并行运行测试。在Maven的surefire插件中配置<parallel>methods</parallel>和<threadCount>4</threadCount>。注意：并行测试要求测试之间绝对独立，不能有共享状态。
3. 重用Spring上下文： 对于Spring集成测试，启动容器是最耗时的部分。Spring TestContext Framework默认会为每个测试类缓存应用上下文。确保你的测试配置（@ContextConfiguration）是相同的，以最大化上下文重用。
4. 使用内存数据库： 在测试中绝对不要连接生产或开发数据库。使用H2、HSQLDB等内存数据库，它们速度快且易于清理。
5. 避免不必要的日志： 测试中过多的日志输出（尤其是到控制台）会拖慢速度。在测试的logback或log4j配置中，将日志级别设为WARN或ERROR。

8.3 测试代码的“坏味道”与重构

• 脆弱测试： 对内部实现细节（如私有字段、特定方法调用顺序）断言过多，导致生产代码稍有改动（即使是重构，不改变功能）测试就失败。应对： 测试应该关注公共API的行为和输出，而不是实现细节。
• 冗长测试： 一个测试方法有几十行准备代码。应对： 提取Helper方法或使用Builder模式构建测试数据。
• 重复测试： 多个测试方法有大量相同的准备代码。应对： 将公共准备逻辑移到@Before方法或父类中。
• 测试逻辑复杂： 测试方法里充满了条件判断和循环。应对： 测试代码应该简单直白。如果测试逻辑复杂，说明被测方法可能职责过多，需要考虑拆分。
• 忽略测试： 代码库中存在大量被@Ignore的测试。应对： 定期审查被忽略的测试，修复它们或直接删除。被忽略的测试会给人“测试覆盖良好”的假象。

编写单元测试是一个需要持续练习和反思的技能。它不仅仅是验证代码正确性的工具，更是一种设计驱动。当你发现一个类很难测试时，这往往是一个强烈的信号，提示你的代码耦合度太高、职责不够单一，是时候进行重构了。从这个角度看，单元测试是提升代码质量的最佳实践之一，而JUnit4则是你实践这一理念的得力伙伴。从今天开始，为你写的每一段核心业务逻辑，都配上一个简洁、清晰、高效的单元测试吧。