使用JUnit的assertThrows验证异常类型与消息，结合Mockito模拟异常场景，确保异常处理逻辑正确。
在Java开发中，异常处理和单元测试的结合能有效提升代码的健壮性和可维护性。通过单元测试验证异常是否被正确抛出或处理，可以确保程序在出错时行为符合预期。重点在于使用测试框架（如JUnit）提供的机制来断言异常的发生。
使用JUnit测试异常是否被正确抛出
当某个方法在特定输入下应抛出异常时，应在单元测试中明确验证这一点。JUnit 5提供了简洁的方式进行异常断言。
示例：测试参数为null时抛出IllegalArgumentException
@Test
void shouldThrowExceptionWhenInputIsNull() {
Throwable exception = assertThrows(IllegalArgumentException.class, () -> {
myService.process(null);
});
assertEquals("Input must not be null", exception.getMessage());
}
这种方式不仅能确认异常类型，还能检查异常消息是否符合预期。
测试自定义异常的处理逻辑
项目中常会定义自己的异常类型，比如D
ataNotFoundException、InvalidOrderException等。单元测试应覆盖这些异常被抛出的场景，并验证其携带的信息。
可以在业务方法中模拟数据访问失败的情况，观察是否抛出预期的自定义异常。
建议做法：- 在测试中构造触发异常的条件，如数据库返回空结果
- 使用assertThrows捕获异常并验证其类型和消息
- 必要时检查异常中的附加信息，如错误码或上下文数据
结合try-catch进行更复杂的异常流程测试
某些情况下，方法不会直接抛出异常，而是在内部捕获并处理。此时需验证异常是否被正确记录或转换。
例如，服务层捕获底层异常并包装为统一的业务异常：
- 在测试中模拟底层抛出SQLException
- 调用服务方法，验证最终抛出的是ServiceException而非原始异常
- 可借助Mockito模拟DAO层行为，精确控制异常触发点
利用@DisplayName和断言提升测试可读性
清晰的测试命名和精准的断言有助于团队理解异常处理意图。
使用@DisplayName描述测试场景，比如“当用户ID不存在时应抛出UserNotFoundException”，配合assertThrows和message验证，使测试本身成为文档。
基本上就这些。关键是把异常视为正常行为的一部分，在测试中主动设计异常路径，而不是只关注成功流程。这样写的代码更可靠，后期维护也更容易。
