第9讲：Service层测试与异常处理

09Service层测试与异常处理保障业务逻辑的健壮性与可维护性，构建高可靠的后端服务基石Service层单元测试策略通过Mock隔离外部依赖，聚焦业务逻辑验证，确保核心流程覆盖与边界条件处理的准确性。系统化异常设计与治理定义清晰的业务异常体系，规范异常捕获与统一响应机制，提升系统容错能力与问题排查效率。本讲目标Service层单元测试熟练运用JUnit5与Mockito框架，对Service层核心业务逻辑开展单元测试。通过隔离外部依赖，精准验证业务流程的完整性与计算结果的正确性，筑牢代码质量防线。自定义异常设计深入理解自定义业务异常的设计思路，将底层系统异常转化为贴合业务场景的语义化异常信息。规范异常层级与分类，为后续统一处理和向用户返回友好提示奠定基础。全局异常处理掌握@RestControllerAdvice与@ExceptionHandler注解的组合使用，构建集中式的全局异常捕获机制。统一处理各类异常并格式化响应数据，显著提升系统的健壮性与用户体验。核心价值：建立完整的测试防护网与异常治理体系，保障业务逻辑可靠、系统运行稳定。Service层单元测试01为什么需要单元测试？验证业务逻辑：确保每个方法的行为严格符合预期，防止逻辑漏洞。提高代码质量：在开发阶段发现潜在Bug，降低后续修复成本，提升系统稳定性。驱动重构与文档：测试用例是可执行的技术文档，也让代码重构更加安全、无后顾之忧。02核心测试框架Mockito

强大的Mock框架，隔离外部依赖，专注业务逻辑本身的测试。JUnit5

Java生态最主流的单元测试框架，提供了丰富的注解（如@Test、@BeforeEach）和断言方法，规范测试流程。03标准测试步骤STEP1-3准备与注入

配置测试环境，通过@Mock创建依赖对象，使用@InjectMocks将Mock对象注入到目标Service中。STEP4定义Mock行为

使用when(...).thenReturn(...)语法，预设依赖方法的返回值，控制测试的输入条件。STEP5-6执行与验证

调用目标方法，通过断言验证结果，并用verify(...)确认依赖方法的交互行为。Mockito核心注解与方法@Mock创建一个虚拟的Mock对象，其行为完全由开发者定义，不依赖真实对象的实现逻辑，用于模拟外部依赖。@InjectMocks自动将所有标记为@Mock的对象注入到被测试的目标对象中，简化了测试类中依赖对象的手动赋值过程。@Spy创建真实对象的包装对象，默认调用真实方法，同时允许对特定方法进行Mock，适用于部分模拟的场景。when(...).thenReturn(...)定义方法的桩打（Stub）行为，指定当调用Mock对象的某个方法时，返回预设的固定值或抛出指定异常。verify(...)验证Mock对象的某个方法是否被调用、调用的次数以及调用时的参数是否符合预期，确保交互逻辑正确。ArgumentMatchers.any()参数匹配器，用于匹配方法调用时的任意参数值，支持各种数据类型，灵活处理不关心具体参数的验证场景。案例：Service层单元测试被测试的核心业务逻辑(UserService)@ServicepublicclassUserService{@AutowiredprivateUserRepositoryuserRepository;publicUsergetUserById(Longid){returnuserRepository.findById(id).orElseThrow(()->newUserNotFoundException("Usernotfound"));}}该服务类依赖UserRepository进行数据查询。核心逻辑是根据ID查找用户，若不存在则抛出自定义异常UserNotFoundException。单元测试实现(Mockito+JUnit5)@ExtendWith(MockitoExtension.class)classUserServiceTest{@MockUserRepositoryrepo;@InjectMocksUserServiceservice;@TestvoidshouldReturnUserWhenExists(){//1.准备数据&2.定义Mock行为when(repo.findById(1L)).thenReturn(Optional.of(newUser(1L,"test")));//3.执行&4.验证Userres=service.getUserById(1L);assertNotNull(res);verify(repo).findById(1L);}@TestvoidshouldThrowWhenNotFound(){when(repo.findById(999L)).thenReturn(Optional.empty());assertThrows(UserNotFoundException.class,()->service.getUserById(999L));}}利用@Mock模拟数据层依赖，解耦数据库；通过when/thenReturn预设行为，覆盖“正常返回”和“异常抛出”两个核心场景，确保业务逻辑的健壮性。自定义业务异常业务语义更清晰将系统底层异常（如SQLException）转化为贴合业务场景的异常（如UserNotFoundException），代码可读性大幅提升，便于团队协作理解。实现全局统一处理可根据异常类型映射不同的HTTP状态码和友好提示信息，通过全局异常处理器集中拦截，避免在业务代码中重复编写异常捕获逻辑。解耦业务与异常逻辑Service层专注抛出业务异常，Controller层专注捕获和响应处理，职责分明，符合单一职责原则，让核心业务逻辑代码更纯粹。通过定义基础异常类并派生子类，构建层级清晰的业务异常体系，让异常处理更规范。//基础业务异常类publicclassBusinessExceptionextendsRuntimeException{privateintcode;//错误状态码publicBusinessException(Stringmsg,intcode){super(msg);this.code=code;}}//派生具体业务异常publicclassUserNotFoundExceptionextendsBusinessException{publicUserNotFoundException(Stringmsg){super(msg,404);}}核心思路：定义基础父类+扩展具体子类，实现异常体系的标准化管理。全局异常处理@RestControllerAdvice一个特殊的@Component组件，用于集中定义全局的异常处理逻辑。它能自动捕获并处理所有@RestController注解类中抛出的异常，实现统一的异常管理入口。@ExceptionHandler用于在异常处理类中定义处理特定异常的方法。当参数中指定的异常类型被抛出时，该方法会被自动调用，开发者可在此定制针对性的错误响应逻辑。核心实现代码示例@RestControllerAdvice

publicclassGlobalExceptionHandler{

@ExceptionHandler(BusinessException.class)

publicResponseEntity<ErrorResponse>handleBizEx(BusinessExceptione){

returnnewResponseEntity<>(newErrorResponse(e.getCode(),e.getMessage()),HttpStatus.valueOf(e.getCode()));

}

@ExceptionHandler(Exception.class)//兜底处理所有未捕获异常

publicResponseEntity<ErrorResponse>handleAllEx(Exceptione){...}

}统一响应与体验优化当Service层抛出特定业务异常（如UserNotFoundException）时，全局处理器会自动捕获并返回结构统一的JSON错误信息，同时正确设置HTTP状态码（如404），提升系统的健壮性和API的规范性。课后作业核心任务：为订单Service编写单元测试和异常处理针对订单创建Service模块，完成单元测试用例的全覆盖编写，并结合业务场景设计自定义异常体系，实现全局统一的异常捕获与响应处理。01.编写单元测试使用Mockito框架Mock外部依赖，重点测试`createOrder`方法的正常执行流程，以及库存不足等关键异常场景的分支覆盖。02.设计业务异常定义并实现`InsufficientStockException`等针对