1. 项目概述为什么我们需要深入理解JUnit注解在Java开发的世界里单元测试早已不是“可选项”而是保障代码质量、提升开发效率的“必选项”。作为一名写了十多年Java的老兵我见过太多因为测试不充分而引发的线上事故也见证了一个项目从“裸奔”到拥有健壮测试套件后的蜕变。JUnit作为Java单元测试的事实标准其核心——那些看似简单的注解如Test、BeforeEach——恰恰是构建高效、可维护测试用例的基石。很多人只是机械地使用它们却很少深究其背后的设计意图、执行顺序以及组合使用的精妙之处。这就像给你一套精密的瑞士军刀你如果只用来开啤酒瓶那真是暴殄天物了。Test不只是标记一个测试方法那么简单它关联着超时、异常断言等高级特性BeforeEach和AfterEach也不仅仅是“前后”执行它们共同构成了测试生命周期管理的核心。理解这些注解意味着你能写出更清晰、更健壮、执行更快的测试而不是一堆脆弱、难以维护的“面条代码”。尤其是在微服务、持续集成/持续部署CI/CD成为主流的今天一套可靠的自动化测试是代码能够安全、快速上线的最后一道也是最重要的一道防线。本文将带你深入JUnit 5目前的主流版本的注解体系从最常用的到进阶组合结合我踩过的坑和总结的最佳实践让你真正掌握这把“瑞士军刀”的每一种用法。2. JUnit 5核心注解体系深度解析JUnit 5的架构相比JUnit 4有了革命性的变化其注解体系也更加清晰和模块化。整个JUnit Jupiter API我们写测试时用的主要API的注解可以大致分为几个功能类别测试声明、生命周期回调、条件测试、参数化测试和元注解/组合注解。理解这个分类是灵活运用的前提。2.1 测试声明类注解定义测试的骨架这类注解是测试类的“钢筋水泥”定义了哪些方法是测试以及测试如何分组和命名。Test测试方法的基石这是最核心的注解没有它JUnit就不会将一个方法识别为测试方法。但它的作用远不止于此。import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; import static java.time.Duration.*; class CalculatorTest { Test void standardTest() { assertEquals(4, 2 2); } Test void testWithTimeout() { // 断言代码执行时间不超过1秒 assertTimeout(ofSeconds(1), () - { // 模拟耗时操作 Thread.sleep(500); }); } Test void testException() { // 断言会抛出特定异常并且异常信息包含特定内容 IllegalArgumentException exception assertThrows( IllegalArgumentException.class, () - { throw new IllegalArgumentException(Invalid argument); } ); assertTrue(exception.getMessage().contains(Invalid)); } }在上面的例子中Test注解的方法standardTest是一个最基础的测试。而testWithTimeout和testException则展示了Test方法内部如何利用JUnit 5的断言assertTimeout,assertThrows来测试超时和异常行为。这里的关键是Test本身不提供这些功能但它标记的方法是这些断言逻辑的载体。注意Test方法必须是void返回类型并且不应该声明任何参数参数化测试除外。这是JUnit框架的硬性规定违反会导致测试无法被识别或执行。DisplayName为测试赋予可读的“名片”默认情况下测试类和测试方法的名字就是它们在报告中的显示名。这对于使用了驼峰命名法或缩写的方法名来说可读性很差。DisplayName允许你使用空格、特殊字符甚至emoji来为测试提供一个更友好的名称。Test DisplayName( 当除数为零时应抛出ArithmeticException异常) void divideByZeroShouldThrowException() { // ... } Test DisplayName(用户注册 - 邮箱格式验证边界情况测试) void testEmailFormatBoundary() { // ... }这个注解极大地提升了测试报告的可读性尤其是在CI/CD流水线的测试结果中一眼就能看出测试的意图而不是去解析一个叫testEdgeCaseForEmailValidationWhenInputIsNull的方法名。RepeatedTest、TestFactory进阶测试声明RepeatedTest(n): 当你需要将一个测试逻辑重复执行n次时使用。每次执行都是一个独立的测试实例拥有独立的生命周期。常用于非确定性逻辑如涉及随机数、并发的稳定性验证。RepeatedTest(5) DisplayName(重复测试随机数生成在有效范围内) void randomNumberWithinRange(RepetitionInfo repetitionInfo) { // repetitionInfo可以获取当前是第几次重复 System.out.println(当前重复次数: repetitionInfo.getCurrentRepetition()); int random generateRandom(1, 100); assertTrue(random 1 random 100); }TestFactory: 用于创建动态测试。它返回的是一个Stream,Collection,Iterable或Iterator的DynamicTest实例。这在需要根据运行时数据如从文件、数据库读取的测试用例动态生成测试时非常有用。它更像一个测试的“工厂方法”而不是一个测试本身。2.2 生命周期回调注解管理测试的“生老病死”JUnit 5为测试生命周期提供了清晰的回调点这是编写稳定、独立测试的关键。理解它们的执行顺序至关重要。执行顺序与范围BeforeAll/AfterAll: 在整个测试类的所有测试方法执行之前/之后各执行一次。它们必须是static方法。通常用于昂贵资源的初始化与清理如启动嵌入式数据库、建立网络连接池。class DatabaseTest { static EmbeddedDatabase db; BeforeAll static void initAll() { db new EmbeddedDatabaseBuilder().build(); // 执行一次全局schema初始化 db.execute(CREATE TABLE IF NOT EXISTS users (...)); } AfterAll static void tearDownAll() { if (db ! null) { db.shutdown(); } } }BeforeEach/AfterEach: 在每个Test,RepeatedTest,ParameterizedTest或TestFactory方法执行之前/之后各执行一次。它们不是静态方法。用于为每个测试准备和清理独立的环境如初始化测试数据、重置Mock对象状态、清理临时文件。class ShoppingCartTest { ShoppingCart cart; Product sampleProduct; BeforeEach void setUp() { cart new ShoppingCart(); // 每个测试都有一个全新的购物车 sampleProduct new Product(P001, Java编程思想, 99.99); } Test void addItemShouldIncreaseCartSize() { cart.addItem(sampleProduct); assertEquals(1, cart.getItems().size()); } AfterEach void tearDown() { cart.clear(); // 确保测试间无状态残留 } }实操心得我强烈建议将BeforeEach用于创建新的对象实例而不是重置共享实例的状态。后者容易在测试并行执行时引入难以排查的竞态条件。对于需要共享的、只读的或创建成本极高的资源才考虑使用BeforeAll。2.3 条件执行与禁用注解让测试更智能不是所有测试在任何环境下都需要或能够运行。条件测试注解让测试执行变得智能化。Disabled临时跳过最简单的条件注解直接禁用某个测试或整个测试类。常用于标记尚未实现的测试、已知存在缺陷的测试或者在重构期间临时跳过。Test Disabled(功能尚未实现待PM确认需求) void futureFeatureTest() { // ... } Disabled(整个类在Windows环境下的测试存在问题) class WindowsSpecificTest { // ... }EnabledOnOs/DisabledOnOs操作系统条件Test EnabledOnOs(OS.LINUX, OS.MAC) void unixOnlyFileOperationTest() { // 只在Linux或Mac上运行 } Test DisabledOnOs(OS.WINDOWS) void notOnWindowsTest() { // 不在Windows上运行 }EnabledIfSystemProperty/EnabledIfEnvironmentVariable系统与环境变量条件这些注解允许你基于系统属性或环境变量来决定是否执行测试。这在配置不同的CI环境如开发、测试、生产时非常有用。Test EnabledIfSystemProperty(named test.profile, matches integration) void integrationTestRequiringExternalService() { // 仅在系统属性 test.profileintegration 时运行 // 命令行可传-Dtest.profileintegration } Test EnabledIfEnvironmentVariable(named CI, matches true) void ciPipelineOnlyTest() { // 仅在CI环境变量CItrue时运行例如在Jenkins、GitHub Actions中 }EnabledIf/DisabledIf自定义条件最灵活的条件注解允许你通过一个返回布尔值的方法来动态决定。Test EnabledIf(customCondition) void testBasedOnCustomLogic() { // ... } boolean customCondition() { // 复杂的判断逻辑例如检查数据库是否可连接特定文件是否存在等 return someExternalService.isAvailable(); }2.4 参数化测试注解 (ParameterizedTest)数据驱动测试的利器当你想用多组不同的输入数据来测试同一个逻辑时参数化测试是完美选择。它让测试代码更简洁数据与逻辑分离更清晰。核心ParameterizedTest必须与一个数据源注解配合使用。ParameterizedTest ValueSource(strings {racecar, radar, level}) void palindromes(String candidate) { assertTrue(StringUtils.isPalindrome(candidate)); }常用数据源注解ValueSource: 提供一组字面值基本类型、String、Class。最简单但类型单一。CsvSource/CsvFileSource: 使用CSV格式提供数据。CsvSource内联在代码中CsvFileSource从类路径或文件系统加载CSV文件。非常适合多参数测试。ParameterizedTest CsvSource({ 1, 1, 2, 2, 3, 5, 10, -5, 5 }) void add(int a, int b, int expectedSum) { assertEquals(expectedSum, a b); } ParameterizedTest CsvFileSource(resources /test-data.csv, numLinesToSkip 1) void testWithCsvFile(String name, int age) { // 从 src/test/resources/test-data.csv 读取数据 }MethodSource: 指定一个返回Stream、Collection等的方法作为数据源。最灵活可以生成复杂的对象。ParameterizedTest MethodSource(provideComplexObjects) void testWithComplexObject(MyDomainObject obj) { assertNotNull(obj.getId()); } static StreamArguments provideComplexObjects() { return Stream.of( Arguments.of(new MyDomainObject(1, Alice)), Arguments.of(new MyDomainObject(2, Bob)) ); }参数显示名定制ParameterizedTest(name ...)使用占位符可以生成易读的测试显示名。ParameterizedTest(name {index} a{0}, b{1}, sum{2}) CsvSource({1,1,2, 2,3,5}) void testAdd(int a, int b, int sum) { assertEquals(sum, a b); } // 报告中将显示1 a1, b1, sum2, 2 a2, b3, sum52.5 元注解与组合注解提升代码复用与可读性这是JUnit注解体系中一个非常强大但常被忽视的特性。你可以创建自定义的组合注解将多个常用注解聚合在一起。场景假设你的项目中有大量需要连接数据库的集成测试每个测试类都需要SpringBootTest和Transactional用于测试后回滚。你可以创建一个组合注解import org.springframework.boot.test.context.SpringBootTest; import org.springframework.transaction.annotation.Transactional; import org.junit.jupiter.api.extension.ExtendWith; import org.springframework.test.context.junit.jupiter.SpringExtension; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; Target(ElementType.TYPE) Retention(RetentionPolicy.RUNTIME) // 必须为RUNTIMEJUnit才能在运行时识别 SpringBootTest Transactional ExtendWith(SpringExtension.class) // 如果使用JUnit 4风格运行器需要这个JUnit 5通常不需要 public interface IntegrationTest { // 可以定义一些属性 }然后你的测试类就可以简化为IntegrationTest class UserRepositoryIntegrationTest { // ... 测试方法 }这不仅仅减少了代码重复更重要的是统一了配置避免了因复制粘贴导致的配置不一致错误。你还可以为特定类型的测试如性能测试、契约测试创建专用的组合注解使测试意图更加清晰。3. 注解在Spring Boot测试中的实战应用在现代Java企业级开发中Spring Boot与JUnit 5的结合是黄金标准。Spring Boot Test提供了一系列强大的注解与JUnit注解协同工作用于测试从简单组件到完整Web应用的各个层面。3.1 分层测试策略与对应注解一个健康的测试金字塔应该包含大量单元测试、适量的集成测试和少量的端到端测试。不同层次的测试需要使用不同的Spring Boot测试注解。单元测试层MockBean,SpyBean,WebMvcTest(切片测试)这一层关注单个组件如Service、Controller的逻辑外部依赖如Repository、第三方客户端通常被Mock或Stub。MockBean/SpyBean: 并非JUnit注解而是Spring Boot Test提供的。用于向Spring的ApplicationContext中添加Mockito的mock或spy对象以替换真实的Bean。这是隔离被测对象依赖的核心手段。SpringBootTest // 或使用更轻量的 WebMvcTest class OrderServiceTest { Autowired private OrderService orderService; MockBean private PaymentService paymentService; // 模拟支付服务 MockBean private InventoryRepository inventoryRepository; // 模拟库存仓库 Test void placeOrderShouldSucceedWhenInventorySufficient() { // 1. 准备Mock行为 when(inventoryRepository.isStockAvailable(anyString(), anyInt())).thenReturn(true); when(paymentService.process(any(PaymentRequest.class))).thenReturn(new PaymentResult(true, success)); // 2. 执行测试 Order order new Order(item1, 2); OrderResult result orderService.placeOrder(order); // 3. 验证业务逻辑和Mock交互 assertTrue(result.isSuccess()); verify(paymentService, times(1)).process(any(PaymentRequest.class)); } }WebMvcTest:切片测试注解。它只加载与Web MVC层相关的配置如Controller,RestController,ControllerAdvice,Filter等而不会加载完整的Service,RepositoryBean。这使测试非常快速且专注。WebMvcTest(UserController.class) // 只加载UserController相关的配置 class UserControllerTest { Autowired private MockMvc mockMvc; // 模拟HTTP请求的核心工具 MockBean private UserService userService; // Controller依赖的Service需要被Mock Test void getUserByIdShouldReturnUser() throws Exception { User mockUser new User(1L, testUser); when(userService.getUserById(1L)).thenReturn(mockUser); mockMvc.perform(get(/api/users/1) .accept(MediaType.APPLICATION_JSON)) .andExpect(status().isOk()) .andExpect(jsonPath($.username).value(testUser)); } }集成测试层DataJpaTest,SpringBootTest这一层测试多个组件之间的交互通常会启动一个轻量级的Spring上下文并可能使用真实或嵌入式数据库。DataJpaTest: 另一个切片测试注解专注于JPA相关的测试。它会配置一个内存数据库如H2扫描Entity类和Spring Data JPA仓库并自动注入TestEntityManager。它默认会为每个测试方法开启事务并在结束后回滚确保测试数据不污染。DataJpaTest class UserRepositoryTest { Autowired private TestEntityManager entityManager; // 用于操作测试数据的实体管理器 Autowired private UserRepository userRepository; Test void findByUsernameShouldReturnUser() { // 使用TestEntityManager准备数据 User savedUser entityManager.persistFlushFind(new User(null, alice, aliceexample.com)); // 调用真实的Repository方法 User found userRepository.findByUsername(alice).orElse(null); assertNotNull(found); assertEquals(savedUser.getEmail(), found.getEmail()); } }SpringBootTest: 这是功能最全面的测试注解它会加载完整的Spring应用上下文模拟生产环境的启动过程。通常用于需要测试完整应用流程的集成测试或端到端测试。可以通过webEnvironment属性控制Web环境类型。SpringBootTest(webEnvironment SpringBootTest.WebEnvironment.RANDOM_PORT) // 启动一个随端口的真实Servlet容器 class FullContextIntegrationTest { Autowired private SomeService service; // 可以注入任何Bean LocalServerPort private int port; // 注入随机分配的端口 Test void testServiceAndEndpointTogether() { // 可以测试Service逻辑 String result service.doSomething(); assertEquals(expected, result); // 也可以使用TestRestTemplate测试REST端点 TestRestTemplate restTemplate new TestRestTemplate(); ResponseEntityString response restTemplate.getForEntity( http://localhost: port /api/endpoint, String.class); assertEquals(HttpStatus.OK, response.getStatusCode()); } }3.2 测试配置与属性覆盖在测试中我们经常需要使用与生产环境不同的配置例如指向内存数据库、禁用某些外部服务调用等。TestPropertySource: 用于为特定的测试类或方法指定属性文件或内联属性优先级高于application.properties。SpringBootTest TestPropertySource(properties { spring.datasource.urljdbc:h2:mem:testdb, external.api.enabledfalse }) class TestWithOverriddenProperties { // 测试将使用内存H2数据库并禁用外部API调用 }ActiveProfiles: 激活特定的Spring Profile。你可以准备一个application-test.properties文件然后在测试中激活testprofile来加载测试专用配置。SpringBootTest ActiveProfiles(test) // 会加载 application-test.properties class TestWithTestProfile { // ... }3.3 事务管理与回滚数据库集成测试中保持测试的独立性是关键。Spring的Transactional注解在这里扮演重要角色。Transactional: 在测试类或方法上使用会使测试方法在一个事务中执行并在方法结束后自动回滚。这是DataJpaTest和SpringBootTest当包含spring-boot-starter-jdbc时的默认行为。这确保了每个测试都不会在数据库中留下数据影响后续测试。SpringBootTest Transactional // 显式声明确保回滚 class TransactionalServiceTest { Autowired private UserService userService; Test void createUserShouldPersistData() { User user new User(test); userService.createUser(user); // 此处数据已插入数据库 assertNotNull(user.getId()); } // 测试方法结束后上面插入的数据会被自动回滚数据库状态恢复 }Commit: 如果你希望某个测试方法提交事务例如你想验证数据库约束或触发器可以在该方法上使用Commit注解它会覆盖类级别的Transactional回滚行为。Rollback: 与Commit相反显式指定回滚默认就是true。Rollback(false)表示不自动回滚。踩坑记录事务回滚虽然方便但要小心测试方法中捕获了异常的情况。如果测试方法捕获了异常并且没有重新抛出Spring会认为测试执行成功事务可能会被提交而不是回滚。确保在需要回滚的测试中让异常正常抛出。4. 高级技巧、常见问题与性能优化掌握了基础注解和Spring集成后我们来看看如何写出更专业、更健壮、执行更快的测试。4.1 测试执行顺序的控制默认情况下JUnit并不保证测试方法的执行顺序这是为了鼓励编写独立的测试。但在某些特殊场景如集成测试中需要按顺序初始化数据你可能需要控制顺序。TestMethodOrder: 类级别注解用于指定测试方法的排序策略。MethodOrderer实现:MethodOrderer.DisplayName: 按DisplayName字母顺序。MethodOrderer.MethodName: 按方法名字母顺序。MethodOrderer.OrderAnnotation: 按Order注解指定的数值顺序。MethodOrderer.Random: 随机顺序默认行为的显式声明。MethodOrderer.Alphanumeric: 按方法名的字母数字顺序已废弃建议用MethodName。TestMethodOrder(MethodOrderer.OrderAnnotation.class) class OrderedTests { Test Order(3) void testC() { System.out.println(C); } Test Order(1) void testA() { System.out.println(A); } Test Order(2) void testB() { System.out.println(B); } } // 输出顺序A, B, C重要原则尽量避免依赖测试执行顺序。如果测试间存在依赖通常意味着测试设计有问题不够独立。这会导致测试套件脆弱难以维护和并行执行。Order应作为最后的手段仅在处理遗留代码或极其特殊的集成场景时使用。4.2 测试的扩展模型ExtendWithJUnit 5的核心扩展模型基于ExtensionAPI。ExtendWith注解用于注册一个或多个扩展。这些扩展可以在测试生命周期的不同阶段介入提供强大的自定义能力。内置扩展Spring的SpringExtension通过SpringBootTest等隐式注册、Mockito的MockitoExtension等。自定义扩展你可以实现BeforeEachCallback,AfterEachCallback,ParameterResolver等接口来创建自己的扩展。例如创建一个为所有测试自动注入日志器的扩展public class LoggingExtension implements BeforeEachCallback { Override public void beforeEach(ExtensionContext context) { // 获取当前测试实例 Object testInstance context.getRequiredTestInstance(); // 假设测试类有一个Logger字段 Arrays.stream(testInstance.getClass().getDeclaredFields()) .filter(f - f.getType() Logger.class) .forEach(f - { try { f.setAccessible(true); f.set(testInstance, LoggerFactory.getLogger(testInstance.getClass())); } catch (IllegalAccessException e) { throw new RuntimeException(e); } }); } } ExtendWith(LoggingExtension.class) class TestWithCustomExtension { private Logger log; // 会被扩展自动注入 Test void test() { log.info(Test is running with injected logger); } }4.3 常见问题排查与解决java.lang.NoClassDefFoundError或java.lang.ClassNotFoundException(特别是org/junit/platform/commons/...)原因JUnit 5依赖不完整或冲突。JUnit 5由三个主要模块组成JUnit Jupiter (API 引擎), JUnit Platform, JUnit Vintage (用于兼容JUnit 4)。解决检查构建工具依赖。对于Maven确保有dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.9.3/version !-- 使用最新稳定版 -- scopetest/scope /dependency对于GradletestImplementation org.junit.jupiter:junit-jupiter:5.9.3 testRuntimeOnly org.junit.platform:junit-platform-launcher同时排除可能存在的旧版本JUnit 4依赖如junit:junit。Test注解无法识别 (IDEA中显示为灰色或报错)原因IDEA没有正确配置使用JUnit 5作为测试运行器或者模块的测试依赖路径未正确设置。解决检查项目的Project Structure-Modules-Dependencies确保JUnit 5的jar包在Test作用域。在IDEA中右键点击项目或测试目录 -Run All Tests with Coverage如果提示选择Runner选择JUnit 5。或者检查运行配置Run-Edit Configurations-Templates-JUnit确保JUnit 5被选中。Spring Boot测试启动缓慢原因SpringBootTest每次都会加载完整的应用上下文非常耗时。优化使用切片测试尽可能用WebMvcTest,DataJpaTest,JsonTest等替代完整的SpringBootTest。缓存应用上下文Spring Boot Test可以缓存上下文。如果多个测试类使用相同的配置由SpringBootTest的属性定义如classes,webEnvironment它们会共享同一个上下文只启动一次。SpringBootTest ContextConfiguration // 使用默认配置同类配置的测试会共享上下文 class TestA { /* 首次启动会加载上下文 */ } SpringBootTest // 配置相同会复用TestA加载的上下文 class TestB { /* 启动非常快 */ }惰性加载Bean在Spring Boot 2.2中可以在SpringBootTest中设置properties {spring.main.lazy-initializationtrue}这会延迟Bean的初始化直到真正被使用时可以加快测试启动速度但可能会掩盖一些启动时的配置错误。MockBean导致上下文重启拖慢测试原因MockBean会修改Spring的ApplicationContext因为它定义了一个新的Bean定义。Spring Test Framework默认会为每个使用了不同MockBean组合的测试类创建一个新的上下文。优化将MockBean提升到抽象基类如果一组测试类Mock相同的Bean可以创建一个抽象基类在其中定义MockBean子类继承它。这样这些测试类可能共享同一个上下文。审视测试设计是否过度使用了SpringBootTestMockBean也许很多测试可以降级为使用ExtendWith(MockitoExtension.class)的纯单元测试完全不需要Spring上下文速度极快。使用Mock代替MockBean在不需要Spring容器参与即不涉及依赖注入、AOP等的纯逻辑测试中直接使用Mockito的Mock和InjectMocks。测试并行执行JUnit 5原生支持并行执行测试。可以通过配置文件启用在src/test/resources下创建junit-platform.properties文件# 启用并行执行 junit.jupiter.execution.parallel.enabled true # 配置默认的执行模式 junit.jupiter.execution.parallel.mode.default concurrent # 配置类的执行模式 junit.jupiter.execution.parallel.mode.classes.default same_thread注意事项并行测试要求测试必须是独立的不能共享状态如静态变量、单例Bean的可变状态。使用BeforeEach初始化而非BeforeAll避免使用static字段存储测试状态。对于集成测试尤其是涉及数据库的并行执行需要更仔细的设计如使用独立的数据库模式或事务隔离。4.4 测试代码的结构与可维护性写出好的测试代码和写出好的生产代码一样重要。遵循Given-When-Then模式这是行为驱动开发BDD的结构能让测试意图极其清晰。Test void transferMoneyShouldSucceedWhenBalanceSufficient() { // Given: 准备测试数据和状态 Account fromAccount new Account(A1, 1000); Account toAccount new Account(A2, 500); BankService service new BankService(); // When: 执行被测操作 service.transfer(fromAccount, toAccount, 200); // Then: 验证结果和行为 assertEquals(800, fromAccount.getBalance()); assertEquals(700, toAccount.getBalance()); }使用有意义的断言信息在断言方法中提供失败时的提示信息。assertEquals(转账后发送方余额不正确, 800, fromAccount.getBalance()); assertTrue(账户状态未激活, account.isActive(), () - 账户 account.getId() 应该是激活状态); // 注意使用SupplierString来延迟消息构建避免不必要的字符串拼接开销。提取工具方法和常量将重复的测试数据准备、对象构建逻辑提取到辅助方法或常量中。为测试类和方法起好名字测试方法名应该描述其行为例如shouldThrowExceptionWhenInputIsNull比testAdd1好得多。结合DisplayName使用效果更佳。理解并熟练运用JUnit和Spring Boot的测试注解是成为一名高效、可靠的Java开发者的必备技能。它不仅能帮你写出bug更少的代码更能通过快速反馈的自动化测试赋予你重构和演进代码的勇气。从今天起不要再把Test仅仅看作一个标记深入它的世界你会发现编写测试也可以是一种享受。