JUnit测试调用assertEquals报方法歧义错误原因咨询

该编译错误由Java自动装箱/拆箱机制与JUnit方法重载的匹配歧义导致，仅会触发在你写的两行带"second attempt"自定义消息的三参数assertEquals调用上，前面四个两参数断言不受影响。
JUnit中assertEquals有多个重载实现，和当前调用场景相关的两个三参数重载为：

• assertEquals(String message, Object expected, Object actual)：通用对象断言，第一个入参为自定义报错提示
• assertEquals(String message, long expected, long actual)：long原始类型专用断言，第一个入参为自定义报错提示

你调用时传入的第二个参数是42/99这类int原始类型字面量，第三个参数是list.get(0)返回的Integer包装类对象：

• 若匹配第一个重载，仅需将int类型的预期值自动装箱为Integer（Object子类），1步类型转换即可完成匹配
• 若匹配第二个重载，需要将int类型预期值自动拓宽为long，同时将Integer类型的实际值自动拆箱后再拓宽为long，整体转换优先级和前者完全持平
  编译器无法判定要调用的重载版本，就会抛出方法歧义的编译错误。

前四个两参数assertEquals不触发报错，是因为两参数场景下两类重载的类型转换步数存在明确高低差，编译器可以直接确定要调用的实现。

任选一种调整即可解决问题：

• 显式将int类型的预期值转为Integer包装类型，强制匹配通用对象重载，修改示例：

assertEquals("second attempt", Integer.valueOf(42), list.get(0));
assertEquals("second attempt", Integer.valueOf(99), list.get(3));

• 显式将list返回的Integer值拆箱为原始数值类型，匹配原始类型专用重载，例如将list.get(0)替换为list.get(0).intValue()
• 升级JUnit版本至4.13及以上，或直接使用JUnit 5，高版本已经新增了int原始类型对应的assertEquals重载，从根源上规避了这类歧义问题。

内容的提问来源于stack exchange，提问作者Sahil