JUnit 5中org.junit.Assert与jupiter.api.Assertions包方法的核心差异

这两个同名的assertArrayEquals方法虽然都能完成基础的数组相等校验，但从框架定位、实现逻辑到适配场景都存在本质区别，并非完全等价的可替换API。

代际归属差异 #

• org.junit.Assert 是JUnit 4 版本的原生核心断言类，从JUnit 4.0正式版开始就作为整个JUnit 4生态的标准断言入口存在
• org.junit.jupiter.api.Assertions 是JUnit 5（也称Jupiter版本，是JUnit团队对框架做完全重构后的新一代版本）的原生核心断言类，属于JUnit 5模块化体系下的标准配套组件

实现逻辑差异 #

看似同名的数组校验方法，底层实现有明显区别：

• JUnit 4的Assert类中的数组断言仅做浅层元素遍历比较，针对多维对象数组、嵌套结构的数组，不会递归比对内部元素值，很容易出现校验通过但实际数组内容不一致的问题
• JUnit 5的Assertions类中的同名数组断言，做了递归深度比较优化，不管是基本类型数组还是多维对象数组，都会逐层校验每一层的元素值，校验精度更高

除此之外，JUnit 5的断言类还做了泛型优化，减少不必要的编译警告，新增了适配Java 8 Lambda的断言重载、自定义比较器支持、失败消息延迟构造（仅在断言不通过时才拼接提示文本，避免无意义的字符串构造开销）等优化，这些都是JUnit 4的Assert类不具备的能力。

运行流程适配差异 #

很多项目能同时跑通两类断言，核心是因为多数引入JUnit 5的工程都会额外引入junit-vintage-engine兼容组件，专门用来适配老的JUnit 4 API的执行流程

• 导入org.junit.Assert的断言逻辑，实际是走JUnit 5的Vintage兼容层执行，不属于Jupiter引擎的原生执行链路，存在额外的兼容层开销
• 导入org.junit.jupiter.api.Assertions的断言逻辑，是完全走JUnit 5原生的测试发现、执行链路，能直接配合JUnit 5的嵌套测试、参数化测试、测试生命周期回调等新特性联动

实际选型建议 #

• 新编写的测试代码优先选择org.junit.jupiter.api.Assertions的方法，避免后续框架升级、依赖清理时出现兼容断层
• 存量JUnit 4的老测试代码无需强制修改导入，依靠兼容层即可正常运行，可降低存量代码的重构成本

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