AssertJ核心库中StandardRepresentation对未引用字符串处理的回归问题分析

AssertJ作为Java领域广泛使用的断言库，其3.27.x版本在处理未引用字符串(UnquotedString)时出现了一个值得注意的行为变化。本文将深入分析该问题的技术背景、影响范围及解决方案。

问题本质

在AssertJ 3.27.x版本中，StandardRepresentation组件对BasicErrorMessageFactory产生的未引用字符串进行了意外的引号包裹处理。这是由于PR #3617引入的改动导致StandardRepresentation将UnquotedString识别为CharSequence类型，进而触发了默认的字符串引号包裹逻辑。

技术背景

BasicErrorMessageFactory是AssertJ中用于构建错误消息的基础工厂类，其unquotedString()方法专门用于生成不需要引号包裹的字符串内容。在3.27.x之前的版本中，这些未引用字符串能够正确保持原始格式。

问题复现

通过以下测试用例可以清晰重现该问题：

@Test
void hasNotFailedWhenFailedShouldFail() {
    assertThat(new TestErrorMessageFactory().create()).isEqualTo("alpha \"bravo\"");
}

static class TestErrorMessageFactory extends BasicErrorMessageFactory {
    public TestErrorMessageFactory() {
        super("%s %s", unquotedString("alpha"), "bravo");
    }
}

预期输出应为"alpha bravo"，但实际输出变成了带引号的格式。

临时解决方案

对于需要使用3.27.x版本的用户，可以采用自定义非CharSequence实现类作为临时解决方案：

private static class UnquotedString {
    private final String string;
    // 实现细节...
}

这种方式通过规避CharSequence接口，使StandardRepresentation回退到toString()方法调用。

官方修复

AssertJ团队已通过提交f308d95和ede5feb修复了此问题。修复方案主要调整了StandardRepresentation对UnquotedString的特殊处理逻辑，确保其保持原有的未引用特性。

最佳实践建议

1. 对于生产环境，建议升级到包含修复的AssertJ版本
2. 如必须使用3.27.x版本，可采用自定义实现类作为过渡方案
3. 在实现自定义错误消息时，注意测试字符串格式化行为是否符合预期

该问题的修复体现了AssertJ团队对API一致性的重视，确保了错误消息生成机制在各种场景下的行为可预测性。