Junit5如何对比复杂嵌套对象并仅展示存在差异的属性

JUnit5原生assertEquals的能力局限 #

为什么自带的断言无法实现Kotest那样的友好差异输出，核心是它的设计定位从一开始就没有覆盖这类复杂对象对比的场景需求：

• 原生对象相等断言的核心逻辑非常简单：直接调用待对比对象自身的equals()方法做二元判断，判断通过就执行后续测试，判断不通过时，直接把expected和actual两个对象的toString()返回值拼接成失败提示抛出。
• 它本身完全没有内置「递归拆解对象内部字段、定位差异所在的嵌套路径、按层级结构渲染diff结果」的能力，不会主动遍历对象的属性结构，自然无法区分到底哪个字段存在偏差。
• 哪怕是Kotlin data class自动生成的equals和toString方法，输出的也只是把所有字段拼接起来的长字符串，遇到多层嵌套的复杂对象时，全量输出的内容会非常冗长，差异位置极不直观，经常需要在IDE里反复滚动才能找到问题点。

多层嵌套对象对比的成熟落地方案 #

完全不需要逐字段编写单独断言、也能控制维护成本的前提下，现有成熟方案都可以实现期望的结构化清晰差异输出：

• Kotest 内置的结构化对象断言：也就是示例中展示的效果，它会主动递归遍历对象的所有字段（包括任意深度的嵌套对象属性）做相等校验，仅对存在差异的字段按树形结构展示具体的预期值和实际值偏差，没有差异的字段不会被全量打印。
• AssertJ 递归字段对比扩展：支持对任意结构的嵌套对象做全字段自动校验，可灵活配置需要忽略的字段、自定义特殊类型的比较规则，断言失败时会输出带完整字段路径的差异提示，不会冗余展示无差异的对象内容。
• 基于JSON序列化的结构化对比思路：将待对比的两个对象序列化为标准JSON结构后做逐节点diff，输出差异所在的JSON路径，适配任意深度的嵌套结构，同样不需要逐字段编写单独断言。

这类方案的共同设计逻辑，是绕开了“直接依赖对象自身equals判断”的传统断言模式，在断言层主动拆解对象结构、递归校验所有层级的属性，仅将存在差异的位置按清晰的路径展示，从根本上解决全量输出冗长、差异难定位的问题，使用和维护的成本与直接调用原生assertEquals基本一致。

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