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

JUnit 5与Mockito实战：非TDD项目向测试驱动开发的渐进式改造指南

news 2026/7/17 6:22:02

1. 项目概述：从“事后补测”到“测试先行”的范式迁移

如果你和我一样，在职业生涯早期接手或维护过一些“祖传”项目，大概率会对这样的场景深有感触：一个看似简单的功能修改，比如在用户注册逻辑里加个字段校验，改完代码后心里总是不踏实。你小心翼翼地点击运行，祈祷着别把哪个八竿子打不着的模块搞崩。更头疼的是，当你试图为这个新加的校验写个单元测试时，发现相关的业务类构造起来异常复杂，依赖了五六个外部服务，数据库连接、缓存、消息队列全搅和在一起，最后只能无奈地写个集成测试草草了事，或者干脆不写，安慰自己“反正功能跑通了”。这种“先写代码，后补测试”（甚至不补）的开发模式，我们姑且称之为“非TDD”模式。它带来的技术债是隐形的，但破坏力是持续的——代码耦合度高、重构如履薄冰、回归测试成本巨大。

而测试驱动开发（TDD）则提供了一套截然不同的解题思路。它不是一个简单的“先写测试”的动作，而是一套完整的开发节奏和设计反馈循环。其核心循环“红-绿-重构”早已被广泛传播：先写一个必定失败的测试（红），再写最少代码让测试通过（绿），最后在不改变外部行为的前提下清理代码（重构）。JUnit 5作为现代Java测试框架的集大成者，其丰富的注解、断言、扩展模型和动态测试能力，为实践TDD提供了极为顺手的工具。但问题来了，对于一个已经存在、测试覆盖率堪忧甚至没有单元测试的“非TDD”项目，我们如何将它一步步改造，引入TDD的实践呢？这绝不是简单地要求大家“从现在开始先写测试”，而是一场涉及技术选型、流程改造、团队认知和遗留代码处理的系统性工程。

本文将聚焦于这个改造过程的上半部分，我会结合自己多次主导这类改造的经验，拆解从零开始将非TDD项目转向TDD的关键步骤、心法以及必须避开的深坑。我们的目标不是一夜之间达到100%的测试覆盖率，而是建立起一个可持续的、能带来正向反馈的TDD实践飞轮。

2. 改造蓝图：策略选择与基础设施搭建

面对一个庞大的遗留项目，直接全面推行TDD是不现实的，甚至会引发团队的抵触。我的策略是“划定边界，由点及面，基础设施先行”。首先，我们需要一块“试验田”。

2.1 识别改造起点：新功能与修改点

最理想的TDD切入场景，是全新的、边界相对清晰的业务功能模块。比如，系统要新增一个“积分兑换优惠券”的功能。从零开始，没有历史包袱，正是实践“红-绿-重构”循环的绝佳机会。如果近期没有全新模块，那么次优选择是对现有功能的修改或增强。例如，需要优化“用户订单查询”的性能，支持更复杂的分页过滤条件。在修改前，我们可以先为这个查询方法的预期新行为编写测试，这同样符合TDD的精神——测试驱动了代码的变更。

绝对要避免一开始就去啃最硬的那块骨头，比如改造一个干行代码、依赖了十几个外部服务的“上帝类”。那会迅速耗尽团队的耐心和信心。选择一个小而具体、业务价值明确、依赖相对简单的点作为突破口。

2.2 统一测试框架与构建工具

一个项目里如果同时存在JUnit 4、TestNG甚至自己写的测试工具类，那将是测试的噩梦。改造的第一步，就是统一测试技术栈。JUnit 5是当前毋庸置疑的首选，它由三个主要子模块组成：

JUnit Platform：作为在JVM上启动测试框架的基础，支持各种测试引擎。
JUnit Jupiter：包含新的编程模型和扩展模型，用于编写测试。
JUnit Vintage：用于兼容运行JUnit 3或4编写的测试。

在Maven项目中，通常需要以下依赖：

<dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter</artifactId> <version>5.10.0</version> <!-- 请使用最新稳定版 --> <scope>test</scope> </dependency>

同时，确保你的构建工具（Maven Surefire或Gradle）支持JUnit 5。对于Maven，需要配置surefire-plugin：

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>3.2.5</version> </plugin>

Gradle则天然支持，只需使用test任务即可。

注意：如果你的项目中有大量旧的JUnit 4测试，不要急于一次性全部迁移。可以暂时保留它们，让JUnit Vintage引擎来运行。我们的策略是，所有新的测试必须用JUnit 5编写，对于旧的测试，可以在每次修改相关生产代码时，顺便将其迁移到JUnit 5，这是一个渐进的过程。

2.3 建立测试基础设施与约定

没有约定的团队协作是混乱的。在开始写第一个TDD测试前，需要建立一些团队共识：

测试代码质量标准：测试代码同样是产品代码，需要保持同样的可读性、可维护性标准。命名应清晰（如shouldReturnEmptyListWhenUserIdIsNull），避免测试方法中的魔法数字和字符串。
测试目录结构：遵循Maven/Gradle标准，测试代码位于src/test/java下，且包结构应与src/main/java中的生产代码一一对应。资源文件放在src/test/resources。
测试数据管理：决定如何使用测试数据。是使用内存数据库（如H2）？还是利用@Sql注解初始化脚本？或者是使用像testcontainers这样的工具启动真实数据库的容器？对于单元测试，应尽可能使用模拟（Mock）和存根（Stub）来隔离外部依赖。

Mock框架选型：Mockito是Java生态中事实上的标准模拟框架，与JUnit 5集成良好。通常一起引入：

<dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>5.11.0</version> <scope>test</scope> </dependency> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-junit-jupiter</artifactId> <version>5.11.0</version> <scope>test</scope> </dependency>

断言库选择：虽然JUnit Jupiter自带的断言（Assertions）已经很强，但很多人更喜欢Hamcrest或AssertJ更富表达力的语法。AssertJ的流式断言非常受欢迎，可以优先考虑。
```
<dependency> <groupId>org.assertj</groupId> <artifactId>assertj-core</artifactId> <version>3.25.3</version> <scope>test</scope> </dependency>
```

把这些基础设施和约定在团队内明确下来，能减少很多后续的沟通成本和风格之争。

3. 核心心法：TDD循环在改造中的具体实践

基础设施就绪后，我们就可以在选定的“试验田”上开始真正的TDD实践了。这个过程不仅仅是写测试，更是通过测试来驱动出更好的软件设计。

3.1 “红”阶段：编写一个明确失败的测试

这个阶段的目标是定义你期望代码完成什么。测试即需求。假设我们要为“用户服务（UserService）”添加一个根据状态筛选用户的功能。

首先，我们不写任何实现，直接写测试。在src/test/java对应的包下创建UserServiceTest。

import org.junit.jupiter.api.Test; import static org.assertj.core.api.Assertions.assertThat; import java.util.List; class UserServiceTest { @Test void shouldReturnActiveUsersWhenFilterByActiveStatus() { // 1. 准备测试数据：假设我们有一个用户列表 List<User> allUsers = List.of( new User("1", "Alice", "ACTIVE"), new User("2", "Bob", "INACTIVE"), new User("3", "Charlie", "ACTIVE") ); // 2. 创建被测试对象（此时UserService和filterByStatus方法都不存在） UserService userService = new UserService(); // 3. 执行待测试的方法 List<User> activeUsers = userService.filterByStatus(allUsers, "ACTIVE"); // 4. 断言结果 assertThat(activeUsers) .hasSize(2) .extracting(User::getName) .containsExactlyInAnyOrder("Alice", "Charlie"); } }

现在运行这个测试，它肯定会编译失败，因为UserService类和filterByStatus方法不存在。这就是“红”。这个失败非常重要，它验证了我们的测试确实能检测到功能缺失。如果测试莫名其妙地通过了，那反而说明测试写错了。

实操心得：在“红”阶段，我习惯把测试方法名写得像一句自然语言陈述，描述在什么条件下应该发生什么。这迫使我在写代码前就把需求想清楚。同时，断言要尽量精确，比如这里不仅检查数量，还检查具体包含的元素，避免模糊的断言导致测试不够健壮。

3.2 “绿”阶段：用最简单的方式让测试通过

现在，我们的任务是用最快的、最简单的、甚至可能是“丑陋”的代码让这个测试变绿。不要考虑设计模式、性能优化，唯一的目标就是通过测试。

我们创建UserService类和filterByStatus方法。

// src/main/java/com/example/service/UserService.java import java.util.List; import java.util.ArrayList; public class UserService { public List<User> filterByStatus(List<User> users, String status) { List<User> result = new ArrayList<>(); for (User user : users) { // 最简单的实现：字符串相等比较 if (status.equals(user.getStatus())) { result.add(user); } } return result; } }

同时创建User类（如果不存在）：

// src/main/java/com/example/model/User.java public class User { private String id; private String name; private String status; // 构造器、getter、setter 省略... }

现在再运行测试，它应该通过了（绿）。这一步的代码可能很幼稚（比如这里硬编码了字符串比较，没有考虑null，没有用枚举），但没关系，TDD允许甚至鼓励这样做。因为我们现在有一个可运行的、通过测试保护的行为。

3.3 “重构”阶段：优化代码结构而不改变行为

测试通过给了我们进行重构的勇气和安全网。现在，看看刚才写的“绿”代码，有哪些可以改进的地方？

status参数用字符串表示容易出错，应该用枚举UserStatus。
方法实现是基本的循环过滤，可以考虑用Stream API使意图更清晰。
输入参数users为null怎么办？是否需要防御性编程？

我们在不修改测试的前提下，重构生产代码：

// 首先，定义枚举 public enum UserStatus { ACTIVE, INACTIVE, SUSPENDED } // 更新User类，status字段类型改为UserStatus public class User { private String id; private String name; private UserStatus status; // ... getter setter } // 重构UserService方法 import java.util.List; import java.util.stream.Collectors; public class UserService { public List<User> filterByStatus(List<User> users, UserStatus status) { // 增加空集合检查，返回空列表而非null是更友好的做法 if (users == null) { return List.of(); } return users.stream() .filter(user -> status.equals(user.getStatus())) .collect(Collectors.toList()); } }

重构完成后，必须立即重新运行测试。如果测试依然全部通过，说明重构成功，没有破坏现有功能。如果测试失败了，就说明重构引入了问题，需要回退或修正。

注意事项：重构的范围可以很小，比如重命名一个变量；也可以涉及结构调整，比如提取一个方法或引入一个设计模式。关键在于，每一步重构后都要运行测试套件。JUnit 5的@RepeatedTest或@ParameterizedTest在这里很有用，它们能帮助我们用多组数据验证重构后的代码依然健壮。

4. 破解遗留代码困局：为无法实例化的类编写测试

在改造旧项目时，最大的拦路虎往往是那些高度耦合、难以实例化的“遗留代码”。一个典型的“上帝服务类”可能长这样：

public class LegacyOrderService { private OrderDao orderDao; // 直接依赖DAO private PaymentGateway paymentGateway; // 依赖外部支付网关 private EmailService emailService; // 依赖邮件服务 private CacheManager cacheManager; // 依赖缓存 // ... 还有更多依赖 // 构造器可能直接初始化了这些依赖，或者从某个全局容器获取 public LegacyOrderService() { this.orderDao = new JdbcOrderDao(); // 具体实现！ this.paymentGateway = new SomePaymentGatewayImpl(); // 具体实现！ // ... } public void processOrder(Order order) { // 业务逻辑与数据库访问、网络调用、缓存操作 deeply coupled orderDao.save(order); paymentGateway.charge(order); emailService.sendConfirmation(order); cacheManager.invalidate("recent_orders"); // ... } }

为这样的类写单元测试几乎是噩梦，因为要运行processOrder，你需要一个真实的数据库、一个可连接的支付网关、一个能发邮件的服务器……这已经变成了集成测试。TDD的第一步“写测试”就卡住了。怎么办？我们需要用到“依赖注入”和“测试替身”这两把钥匙。

4.1 依赖注入改造

首先，目标是让这个类的依赖可以从外部传入，而不是在内部硬编码创建。这是使代码变得“可测试”的关键一步。

将具体类依赖改为接口依赖：查看orderDao,paymentGateway等字段，如果它们现在是具体类，先尝试找到或创建其接口（如OrderDao,PaymentGateway）。

提供设置依赖的方法：

构造器注入（首选）：通过构造器强制传入所有必需依赖。

public class LegacyOrderService { private final OrderDao orderDao; private final PaymentGateway paymentGateway; // ... 其他依赖 public LegacyOrderService(OrderDao orderDao, PaymentGateway paymentGateway /*, ... */) { this.orderDao = orderDao; this.paymentGateway = paymentGateway; // ... } // ... 方法逻辑现在使用这些接口字段 }

Setter方法注入：如果无法立即修改所有调用方，可以先提供setter方法作为过渡。

public void setOrderDao(OrderDao orderDao) { this.orderDao = orderDao; }

这个过程可能无法一蹴而就，尤其是当这个类被很多地方使用时。可以采用“小步快跑”的方式：每次只修改一个依赖，然后为这个修改点编写测试，确保行为不变。

4.2 使用Mockito创建测试替身

一旦依赖可以被注入，我们就可以在测试中使用Mockito来创建“模拟对象”（Mock）或“存根”（Stub），替换掉那些真实的外部依赖。现在，为改造后的LegacyOrderService编写测试：

import org.junit.jupiter.api.Test; import org.junit.jupiter.api.extension.ExtendWith; import org.mockito.InjectMocks; import org.mockito.Mock; import org.mockito.junit.jupiter.MockitoExtension; import static org.mockito.Mockito.verify; import static org.mockito.Mockito.never; @ExtendWith(MockitoExtension.class) // 启用Mockito与JUnit 5的集成 class LegacyOrderServiceTest { @Mock // 声明一个模拟的OrderDao private OrderDao mockOrderDao; @Mock private PaymentGateway mockPaymentGateway; @Mock private EmailService mockEmailService; @InjectMocks // 自动将上面的Mock注入到被测试对象中 private LegacyOrderService orderService; @Test void shouldSaveOrderAndChargePaymentWhenProcessingValidOrder() { // 准备测试数据 Order testOrder = new Order("order-123", 100.0); // 执行待测试方法 orderService.processOrder(testOrder); // 验证交互行为：验证mock对象是否被以预期的方式调用了 verify(mockOrderDao).save(testOrder); // 验证save被调用，且参数是testOrder verify(mockPaymentGateway).charge(testOrder); verify(mockEmailService).sendConfirmation(testOrder); // 可以验证缓存管理器被调用... } @Test void shouldNotChargePaymentWhenOrderAmountIsZero() { Order zeroAmountOrder = new Order("order-456", 0.0); // 假设我们在processOrder内部加了金额判断逻辑 orderService.processOrder(zeroAmountOrder); verify(mockOrderDao).save(zeroAmountOrder); verify(mockPaymentGateway, never()).charge(zeroAmountOrder); // 验证charge方法从未被调用 verify(mockEmailService).sendConfirmation(zeroAmountOrder); } }

通过这种方式，我们完全隔离了数据库、网络和邮件服务。测试只关注LegacyOrderService本身的业务逻辑是否正确，以及它是否按预期与依赖进行了交互。运行速度极快，且不依赖任何外部环境。

踩坑实录：在Mock行为时，一个常见的错误是“过度指定”（Over-specification）。比如，不仅验证了charge方法被调用，还严格验证了它被调用的次数（除非业务上确实要求精确次数），或者验证了一些与当前测试无关的交互。这会导致测试变得脆弱，一旦内部实现细节改变（比如调整了方法调用顺序），即使最终行为正确，测试也会失败。记住，单元测试应该验证“行为”（输出和副作用），而不是“实现细节”。

5. 测试模式与JUnit 5特性应用

掌握了基本循环和破解遗留代码的方法后，我们可以利用JUnit 5提供的高级特性来编写更强大、更清晰的测试，这对于TDD实践是如虎添翼。

5.1 参数化测试：用多组数据驱动行为验证

TDD中，我们经常需要用一个测试方法来验证多组输入输出。手动写多个@Test方法很冗余。JUnit 5的@ParameterizedTest完美解决了这个问题。

假设我们重构了UserService.filterByStatus，现在想测试边界情况，比如输入用户列表为null或空列表：

import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.Arguments; import org.junit.jupiter.params.provider.MethodSource; import java.util.List; import java.util.stream.Stream; import static org.assertj.core.api.Assertions.assertThat; class UserServiceParameterizedTest { private UserService userService = new UserService(); @ParameterizedTest @MethodSource("provideTestDataForFilter") void filterByStatus_ShouldReturnExpectedResult(List<User> input, UserStatus status, List<User> expected) { List<User> actual = userService.filterByStatus(input, status); assertThat(actual).isEqualTo(expected); } private static Stream<Arguments> provideTestDataForFilter() { User activeUser = new User("1", "A", UserStatus.ACTIVE); User inactiveUser = new User("2", "B", UserStatus.INACTIVE); return Stream.of( // 正常情况：混合列表，筛选ACTIVE Arguments.of(List.of(activeUser, inactiveUser), UserStatus.ACTIVE, List.of(activeUser)), // 边界情况：输入为null Arguments.of(null, UserStatus.ACTIVE, List.of()), // 我们重构后对null返回了空列表 // 边界情况：输入为空列表 Arguments.of(List.of(), UserStatus.ACTIVE, List.of()), // 边界情况：筛选一个不存在的状态 Arguments.of(List.of(activeUser), UserStatus.SUSPENDED, List.of()) ); } }

一个测试方法，覆盖了多种场景，测试报告会清晰地显示每组参数的运行结果。这鼓励我们在TDD的“红”阶段就思考更多的边界情况，从而驱动出更健壮的生产代码。

5.2 动态测试与嵌套测试：组织复杂测试场景

对于更复杂的业务场景，比如一个订单的生命周期（创建、支付、发货、完成），我们可以用@Nested注解来组织测试类，让结构更清晰。

import org.junit.jupiter.api.Nested; import org.junit.jupiter.api.Test; class OrderServiceTest { @Nested class WhenOrderIsCreated { @Test void shouldHavePendingStatus() { /* ... */ } @Test void shouldPersistToDatabase() { /* ... */ } } @Nested class WhenOrderIsPaid { @Test void shouldUpdateStatusToPaid() { /* ... */ } @Test void shouldTriggerShipmentProcess() { /* ... */ } } @Nested class WhenOrderIsShipped { @Test void shouldNotifyCustomer() { /* ... */ } } }

嵌套测试在IDE中会以树形结构展示，一目了然。而动态测试（@TestFactory）则允许在运行时动态生成测试用例，适用于从外部文件或数据库加载测试数据的场景。

5.3 测试生命周期与前置后置操作

JUnit 5提供了丰富的生命周期回调注解，帮助我们管理测试环境：

@BeforeEach/@AfterEach: 在每个@Test,@RepeatedTest,@ParameterizedTest等方法前后执行。常用于初始化/清理测试数据。
@BeforeAll/@AfterAll: 在所有测试方法前后执行一次（静态方法）。常用于启动/停止昂贵的共享资源，如数据库连接池。

在TDD中，我倾向于在@BeforeEach中初始化被测试对象（SUT）和其依赖的Mock，确保每个测试都在干净、独立的环境中运行。

class SomeServiceTest { private SomeService serviceUnderTest; @Mock private SomeDependency mockDependency; @BeforeEach void setUp() { // 每次测试前，重新初始化Mock（MockitoExtension会自动处理） // 并创建新的被测试对象实例 serviceUnderTest = new SomeService(mockDependency); } @Test void testSomething() { // 这里的serviceUnderTest和mockDependency都是新鲜的 } }

这种模式避免了测试间的状态污染，是编写可靠单元测试的黄金法则。

6. 改造路上的典型陷阱与应对策略

将TDD引入一个非TDD项目，技术挑战只是一部分，更多的是流程和习惯上的挑战。下面是一些我亲身踩过或见别人踩过的坑。

6.1 陷阱一：测试过于依赖实现细节

这是最常犯的错误之一。测试应该验证“做了什么”（行为），而不是“怎么做”（实现）。

反面例子：测试一个排序方法，不仅断言结果有序，还断言它调用了某个特定类型的排序算法（如快速排序）。一旦内部实现改为归并排序，测试就失败了，尽管外部行为完全正确。
正面做法：只断言排序后的结果符合预期。至于内部是用冒泡排序还是调用Collections.sort()，测试不应关心。

在Mockito验证中也要注意，只验证那些对外部系统产生影响的命令式交互（如保存到数据库、发送消息），避免验证那些纯属内部协调的查询式交互。

6.2 陷阱二：测试变得庞大而缓慢

随着项目增长，测试套件可能变得庞大，运行缓慢，这会让开发人员不愿意频繁运行测试，违背了TDD的快速反馈原则。

原因：测试做了太多集成的事情（启动Spring容器、连接真实数据库、调用外部API）。
解决：
1. 严格分层：单元测试只测单个类或小范围类簇，用Mock隔离所有外部依赖。集成测试和端到端测试另写，并控制其数量和运行频率。
2. 使用内存数据库：对于确实需要数据库的测试，使用H2等内存数据库，速度远快于连接MySQL。
3. 利用构建工具并行运行测试：Maven Surefire Plugin和Gradle都支持并行测试执行。
4. 定期清理：删除那些已经过时、重复或价值不高的测试。

6.3 陷阱三：为了覆盖率而写测试

管理层或工具可能会要求达到某个测试覆盖率指标（如80%）。这本身不是坏事，但很容易导致团队为了达标而写一些“废话测试”。

反面例子：为只有getter/setter的POJO（纯数据对象）写测试，或者写一个测试只调用方法但不做任何有意义的断言。
正确心态：测试覆盖率应该是一个结果，而不是目标。我们的目标是驱动设计、保障质量、支持重构。覆盖率工具只是一个帮助我们发现未被测试覆盖的代码区域的辅助手段。应该关注于为复杂的业务逻辑、容易出错的边界条件编写有意义的测试，而不是盲目追求数字。

6.4 陷阱四：忽视测试代码的可维护性

测试代码也是代码，同样需要维护。混乱的测试代码会成为项目的负担。

坏味道：测试方法长达几百行、充斥着重复代码、魔法字符串和数字、断言逻辑晦涩难懂。
重构策略：
1. 提取工具方法：将常见的测试数据准备（如createTestUser()）和断言（如assertUserIsActive(User user)）提取成私有方法。
2. 使用建造者模式或Object Mother模式：简化复杂测试对象的构建。
3. 保持测试单一职责：一个测试方法只验证一个行为或一个场景。
4. 给测试起好名字：测试方法名应该清晰地表达其意图，让人不看实现也能猜出在测什么。