JUnit 5 中断言异常消息匹配多个可能顺序的字符串_技术教程

在 junit 5 测试中，当被测方法抛出的异常消息包含动态拼接的集合元素（如 `b, c, d`）且顺序不确定时，直接用 `assertthrows(..., "expected message")` 会因元素遍历顺序不稳定而偶发失败；本文提供两种稳定、原生、无需第三方库的解决方案：固定迭代顺序构造输入数据，或对异常消息进行结构化解析断言。

在使用 Preconditions.checkArgument 等校验逻辑时，若错误消息依赖 Set 的 stream().filter(...).iterator() 遍历结果（如 Joiner.on(", ").join(...)），其输出顺序由底层 Set 实现决定。HashSet 不保证迭代顺序，导致测试中异常消息如 "The strings b, c, d..." 可能变为 "The strings d, b, c..."，使基于完整字符串匹配的 assertThrows 断言不可靠。

✅ 方案一：控制输入，确保顺序可预测（推荐）

最简洁、可维护性最高的方式是在测试中主动提供有序集合，而非依赖实现细节。LinkedHashSet 按插入顺序迭代，完全符合需求：

@Test
void funcSubSet_throwsWithConsistentMessage() {
    // 使用 LinkedHashSet 替代 HashSet，保证 filter 后 stream 的顺序稳定
    Set setA = new LinkedHashSet<>(Arrays.asList("a", "b", "c", "d"));
    Set setB = new LinkedHashSet<>(Arrays.asList("a"));

    // 注入到被测对象（假设 funcSubSet 支持参数化或可重写）
    // 或通过重构将集合作为参数传入：funcSubSet(setA, setB)

    IllegalArgumentException ex = assertThrows(
        IllegalArgumentException.class,
        () -> funcSubSet(setA, setB)
    );

    assertEquals(
        "The strings b, c, d are present in setA but not in setB",
        ex.getMessage()
    );
}

? 关键点：此方案要求被测方法支持外部传入集合（即解耦数据构造与业务逻辑），这既是测试友好的设计，也提升了代码内聚性与可读性。

✅ 方案二：解析式断言 —— 对异常消息做语义校验

若无法修改被测方法签名或输入构造方式（如 setA/setB 是私有字段且不可注入），则应放弃“全字符串匹配”，转为校验消息结构 + 关

键内容存在性：

@Test
void funcSubSet_throwsWithCorrectContentRegardlessOfOrder() {
    Exception ex = assertThrows(Exception.class, () -> funcSubSet());

    String msg = ex.getMessage();

    // 校验固定前缀与后缀
    assertTrue(msg.startsWith("The strings "), "Message must start with 'The strings '");
    assertTrue(msg.endsWith(" are present in setA but not in setB"), 
               "Message must end with ' are present in setA but not in setB'");

    // 提取中间变量部分（去除前后固定文本）
    String variablesPart = msg.substring(
        "The strings ".length(),
        msg.length() - " are present in setA but not in setB".length()
    ).trim();

    // 分割并校验每个缺失元素是否都存在（忽略顺序和空格）
    Set expectedMissing = Set.of("b", "c", "d");
    Set actualMissing = Arrays.stream(variablesPart.split(",\\s*"))
                                      .map(String::trim)
                                      .collect(Collectors.toSet());

    assertEquals(expectedMissing, actualMissing, 
                 "Missing elements mismatch: expected " + expectedMissing + ", got " + actualMissing);
}

该方案完全基于 JUnit 5 原生 Assertions，不引入 AssertJ、Hamcrest 等额外依赖，同时具备强健性：即使消息中多出空格、换行或标点微调，只要语义正确即可通过。

⚠️ 注意事项与最佳实践

避免 HashSet 在测试敏感路径中：生产代码中若消息顺序影响用户体验或日志分析，也建议统一使用 LinkedHashSet 或 TreeSet（按字典序）。
不要用 contains() 粗粒度校验：例如 assertTrue(msg.contains("b") && msg.contains("c")) 易受误匹配干扰（如 "ab" 被误认为含 "b"），应先分割再精确比对。
优先重构而非绕过问题：异常消息顺序不可控本质是测试脆弱性的信号，推动将集合构造逻辑外移，比在测试中不断修补断言更可持续。

综上，控制输入顺序是首选策略；结构化解析是兜底方案。二者均立足 JUnit 5 原生能力，兼顾可靠性、可读性与工程可维护性。