为什么在 Java 项目中测试异常很重要
在任何 Java 应用中，异常都是程序表达错误的一种方式。当出现问题时——无论是无效的输入、缺失的数据，还是连接失败——抛出异常可以提示开发者或系统进行适当处理。因此，测试异常与验证正常输出同样重要。
JUnit 4 依然是许多 Java 团队广泛使用的测试框架。掌握如何正确地测试异常，可以确保代码的失败路径也被覆盖。否则，应用程序可能在边界情况下行为不确定，悄悄吞掉错误，甚至在生产环境中崩溃。
测试异常不仅是验证“是否抛出错误”，更重要的是验证“是否抛出了正确的错误，以及是否在正确的时机”。这个细微的区别能带来更高的代码信任度，也能在调试和重构时节省大量时间。
传统方法：使用 @Test 的 expected 参数
JUnit 4 最早期支持异常测试的方法之一是使用 @Test 注解中的 expected 参数。这是一种简洁的方式，直接在注解中指定预期抛出的异常类。如果测试方法执行过程中抛出了这个异常，测试就会通过。
例如，在方法前加上 @Test(expected = IllegalArgumentException.class)，JUnit 就会验证是否抛出了指定异常。这个方法简洁直观，适用于只关心异常类型而不关心消息或原因的简单测试。
但该方法不能检查异常的消息内容或其他细节。如果一个方法中多个路径都可能抛出相同类型的异常，测试无法判断是否触发了预期的场景。这时候，就需要更灵活的方式。
使用 try-catch 块获得更多控制权
当开发者需要深入检查异常细节时，可以将测试逻辑放入 try-catch 块中。这样可以在捕获异常后检查类型、消息或其他属性。
在 catch 块中，可以加入断言来验证异常消息是否符合预期，或者是否包含某个关键内容。例如，在捕获 IndexOutOfBoundsException 后检查具体的索引值，有助于区分多个可能的失败路径。
缺点是这种写法会让测试变长，降低可读性。如果测试过于程序化，可能会失去单元测试应有的快速反馈能力。但对于关键逻辑路径，这种方式仍然提供了最精确的控制。
使用 ExpectedException 规则实现更好的平衡
JUnit 4 引入了 ExpectedException 规则，以在控制力与简洁性之间取得平衡。它允许开发者声明期望的异常类型，并同时断言异常消息或 cause 等细节，且保持测试代码简洁可读。
在测试类中添加：
java
CopyEdit
@Rule
public ExpectedException thrown = ExpectedException.none();
然后在测试方法中使用：
java
CopyEdit
thrown.expect(SomeException.class);
thrown.expectMessage(“预期的内容”);
这种方式清晰表达测试意图，避免冗长的 try-catch 结构，尤其适合当异常消息与类型一样重要的情况。对于通过异常执行业务规则的系统来说，这种写法能防止未来修改破坏这些规则。
避免异常测试中的假阳性
有时测试之所以通过，只是因为“抛出了一个异常”，但并不是正确的异常。如果只检查异常类型，可能会捕捉到前置代码或设置阶段抛出的异常，造成一种虚假的安全感。
为了避免这种假阳性，开发者应尽可能缩小测试范围，确保抛出异常的代码是唯一可能触发异常的部分。不要在那行代码前放入不必要的逻辑。
保持测试逻辑简洁、断言清晰，可以避免这类问题。测试越精确，结果就越可靠。这是一种长期值得坚持的好习惯，尤其是在系统复杂度增加、异常来源变多时。
测试受检与非受检异常
在 Java 中，异常分为受检异常（Checked）和非受检异常（Unchecked）。受检异常必须被声明和处理，而非受检异常（如 RuntimeException）则不强制声明。两者在 JUnit 4 中的测试结构类似，但思考方式略有不同。
测试受检异常时，方法通常需要添加 throws 子句，或将被测试代码包裹起来确保异常能够抛出。而非受检异常更加灵活，但这并不意味着测试就可以随意或模糊。
无论是测试 FileNotFoundException 还是 IllegalStateException，核心目标都是一致的：验证代码在异常情况下的响应是否正确。这种测试习惯能够提升错误处理质量，并为程序行为提供清晰文档。
有效验证异常消息
有时，异常的消息内容和异常类型一样重要。特别是一些业务规则中，会使用相同的异常类型，但根据情况设置不同的消息。验证消息内容能够确认触发了正确的业务场景。
在 ExpectedException 中，可以使用 expectMessage() 来断言消息内容。你可以匹配完整消息，或者仅匹配部分字符串。如果消息较短且固定，使用完整匹配效果最佳；当只关注部分内容时，可以结合 Hamcrest 的 containsString() 提高灵活性。
保持应用中的错误消息简洁一致，有助于测试代码的可读性。若消息不断变化或不清晰，测试就会变得脆弱。因此，在整个项目中为异常消息制定统一标准是非常有益的做法。
测试异常的原因链（Cause）
有时，一个异常会被包装在另一个异常中。例如，服务层捕获了一个 SQLException，并抛出了自定义的 DataAccessException。此时，异常链中的 cause 携带了重要的上下文，应该被测试。
虽然 JUnit 4 的注解方式不支持检查 cause，但使用 try-catch 或 ExpectedException，仍可调用 getCause() 检查异常来源的类型或消息。
这类测试可以保留异常溯源信息。当系统抛出包装异常时，确认底层异常没有变化，对于维护和排错非常关键。在测试中提早捕捉这些变化，可以加快响应速度，减少生产事故。
保持异常测试的可读性与可维护性
和所有单元测试一样，异常测试也应保持简洁聚焦。过多的设置或细节会让简单测试变得像脚本，难以理解。围绕明确的失败条件组织测试逻辑，会让未来维护更加轻松。
适当的注释也有帮助。简短地说明测试目的，能让下一个开发者快速理解，而不必追踪整个异常调用链。但如果测试本身已经清晰表达了意图，就不必重复说明。
在异常测试中保持一致的命名和结构风格，可以提升团队协作效率。无论是在测试 null 输入还是溢出条件，统一的格式能增强测试的可扫描性和信任感。
通过异常验证业务规则违规
在许多应用中，业务规则是通过自定义异常来强制执行的。例如，尝试提取超出账户余额的金额时，可能会抛出 InsufficientFundsException。这些异常不仅是技术行为，更是向用户传达规则违规的重要手段。
测试这类异常，可以加固业务逻辑，验证限制是否被正确执行，并确保用户获得一致的反馈信息。这类测试不仅是技术保障，也是一种业务行为的文档。
在审计或代码评审中，这类测试往往被特别关注。写得清晰、完备的异常测试，能展示团队对系统行为一致性与用户体验的高度重视。