本文介绍在 junit 5 测试中如何可靠验证异常消息内容，尤其当消息中动态拼接的字符串顺序不确定（如 `set` 迭代顺序不固定）时，避免因元素顺序变化导致断言失败。
在使用 Preconditions.checkArgument 或类似逻辑抛出异常时，若消息依赖 HashSet 等无序集合的遍历结果（例如通过 Joiner.on(", ").join(...) 拼接缺失元素），其输出顺序天然不可预测——这会导致基于完整字符串匹配的测试（如 assertThrows(..., "The strings b, c, d are present...")）间歇性失败。
✅ 推荐方案一：控制输入数据的迭代顺序（首选，治本）
最简洁、可维护性最高的方式是在测试中提供有序的 Set 实现，例如 LinkedHashSet，它保证插入顺序即迭代顺序：
@Test
void funcSubSet_throwsWithPredictableMessage() {
// 使用 LinkedHashSet 显式控制元素顺序
Set setA = new LinkedHashSet<>(Arrays.asList("a", "b", "c", "d"));
Set setB = new LinkedHashSet<>(Arrays.asList("a"));
// 替换原方法中对 setA/setB 的构造逻辑（可通过参数注入或重构为可测试接口）
Exception exception = assertThrows(IllegalArgumentException.class, () -> {
// 假设已重构 funcSubSet(Set, Set) 以接受外部传入
funcSubSet(setA, setB);
});
assertEquals("The strings b, c, d are present in setA but not in setB",
exception.getMessage());
} ? 提示：将集合作为参数传入被测方法（而非在方法内硬编码），不仅提升测试可控性，也符合单一职责与可测试性设计原则。
✅ 推荐方案二：结构化解析 + 内容断言（适用于无法修改被测代码场景）
若无法调整被测方法签名或集合构造方式，则需对异常消息进行语义化校验，而非强依赖字面顺序。利用 JUnit 5 原生 Assertions 即可完成，无需引入 AssertJ 等第三方库：
@Test
void funcSubSet_throwsWithCorrectMissingElements() {
Exception exception = assertThrows(IllegalArgumentException.class,
() -> funcSubSet());
String message = exception.getMessage();
// 1. 验证固定前缀和后缀
assertTrue(message.startsWith("The strings "),
"Expected message to start with 'The strings '");
assertTrue(message.endsWith(" are present in setA but not in setB"),
"Expected message to end with ' are present in setA but not in setB'");
// 2. 提取中间变量部分（去除前后固定文本）
String variablesPart = message.substring(
"The strings ".length(),
message.length() - " are present in setA but not in setB".length()
).trim();
// 3. 验证所有预期缺失元素均存在（忽略顺序与分隔符细节）
Arrays.asList("b", "c", "d").forEach(expected ->
assertTrue(variablesPart.contains(expected),
"Expected missing element '" + expected + "' not found in: " + variablesPart)
);
}该方案健壮性强：即使消息中出现 "d, b, c" 或 "c, d, b"，只要所有目标元素都存在，断言即通过。
⚠️ 注意事项与最佳实践
- ❌ 避免使用 hasMessage(String) 的精确匹配（如 assertThrows(...).hasMessage("...")），因其对空格、标点、顺序极度敏感；
- ✅ 优先采用输入可控 + 有序集合策略，从源头消除不确定性；
- ✅ 对复杂消息，拆解为「结构校验」（前缀/后缀）+「内容校验」（关键词存在性）更可靠；
- ? 若消息格式未来可能扩展（如增加错误码、时间戳），建议进一步提取正则模式（如 Pattern.compile("The strings ([^\\n]+) are present.*")）做分组断言；
- ? 所有示例均仅依赖 org.junit.jupiter.api.Assertions，兼容标准 JUnit 5 环境，零额外依赖。
通过以上任一方式，即可彻底解决因集合迭代顺序导致的异常消息断言不稳定问题，让测试真正反映业务逻辑正确性，而非底层实现细节。
