JUnit 5 中断言异常消息匹配多个可能顺序的字符串方案

本文介绍在 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 '");
    ass
ertTrue(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 环境，零额外依赖。

通过以上任一方式，即可彻底解决因集合迭代顺序导致的异常消息断言不稳定问题，让测试真正反映业务逻辑正确性，而非底层实现细节。