AssertJ核心库中AbstractMapAssert.containsExactly方法的回归问题分析

问题背景

在AssertJ核心库3.25.0版本中，AbstractMapAssert.containsExactly方法出现了一个回归问题。该问题源于一个特定的代码变更，导致在使用Properties类等不允许null值的Map实现时抛出NullPointerException。

问题根源

问题的根本原因在于498ee5bb0a5cc这个提交修改了Maps.java文件中的实现逻辑。新代码尝试将null值放入Map中进行比较，但没有考虑到某些Map实现（如java.util.Properties）不允许存储null值的情况。

Properties类继承自Hashtable，而Hashtable在put方法中会显式检查null值并抛出NullPointerException。这是Java集合框架的一个已知限制，而新的AssertJ实现没有考虑到这种特殊情况。

影响范围

这个问题主要影响以下场景：

1. 使用Properties类进行断言测试
2. 使用其他不允许null值的自定义Map实现
3. 任何调用containsExactly方法进行精确匹配的测试用例

临时解决方案

在官方修复发布前，开发者可以采用以下临时解决方案：

@Test
void workaroundExample() {
    Properties properties = new Properties();
    properties.setProperty("k1", "v1");
    properties.setProperty("k2", "v2");
    
    // 转换为允许null值的Map实现
    Map<String, String> map = new LinkedHashMap<>();
    properties.forEach((k, v) -> map.put((String)k, (String)v));
    
    assertThat(map).containsExactly(entry("k1", "v1"), entry("k2", "v2"));
}

这个方案通过将Properties转换为LinkedHashMap来避免null值检查问题，因为LinkedHashMap允许存储null值。

官方修复方案

AssertJ团队已经决定回滚有问题的提交，并重新评估#2165问题的解决方案。这表明团队非常重视向后兼容性和API的稳定性。

最佳实践建议

1. 在使用Map断言时，了解你的Map实现是否允许null值
2. 考虑在测试中使用防御性拷贝，特别是当使用特殊Map实现时
3. 保持AssertJ库的更新，以获取最新的bug修复
4. 对于关键测试场景，考虑添加额外的null检查逻辑

总结

这个回归问题提醒我们，在编写通用库代码时需要考虑到各种边界情况和不同实现类的特性。AssertJ团队快速响应并决定回滚问题提交的做法值得赞赏，也展示了成熟开源项目对质量的重视。

对于使用者来说，了解所使用的测试工具的限制和特性同样重要，这样才能编写出健壮可靠的测试代码。在遇到类似问题时，采用临时解决方案并等待官方修复是最佳实践。