recursive comparison, four fields differ: Expecting actual: Customer{id=7, name=Asha Patil, email=asha.patil@example.com, address=Address[street=12 MG Road, city=Mumbai, postcode=411001], tags=[vip], creditLimit=5000.0} to be equal to: Customer{id=7, name=Asha Patil, email=asha@example.com, address=Address[street=12 MG Road, city=Pune, postcode=411001], tags=[vip, newsletter], creditLimit=5000.00} when recursively comparing field by field, but found the following 4 differences: field/property 'address.city' differ: - actual value : "Mumbai" - expected value: "Pune" Compared objects have java types and were thus compared with equals method field/property 'creditLimit' differ: - actual value : 5000.0 - expected value: 5000.00 Compared objects have java types and were thus compared with equals method field/property 'email' differ: - actual value : "asha.patil@example.com" - expected value: "asha@example.com" Compared objects have java types and were thus compared with equals method field/property 'tags' differ: - actual value : ["vip"] - expected value: ["vip", "newsletter"] actual and expected values are collections of different size, actual size=1 when expected size=2 The recursive comparison was performed with this configuration: - no equals methods were used in the comparison EXCEPT for java JDK types since introspecting JDK types is forbidden in java 17+ (use withEqualsForType to register a specific way to compare a JDK type if you need it) - these types were compared with the following comparators: - java.lang.Double -> DoubleComparator[precision=1.0E-15] - java.lang.Float -> FloatComparator[precision=1.0E-6] - java.nio.file.Path -> lexicographic comparator (Path natural order) - actual and expected objects and their fields were compared field by field recursively even if they were not of the same type, this allows for example to compare a Person to a PersonDto (call strictTypeChecking(true) to change that behavior). - the introspection strategy used was: DefaultRecursiveComparisonIntrospectionStrategy