no knobs:
  Expecting actual:
    Customer{id=99, name=Asha Patil, email=asha@example.com, address=Address[street=12 MG Road, city=Pune, postcode=411001], tags=[newsletter, 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 5 differences:
  
  field/property 'createdAt' differ:
  - actual value  : 2026-10-26T01:00:00Z
  - expected value: 2026-10-01T10:00:00Z
  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 'id' differ:
  - actual value  : 99L
  - expected value: 7L
  Compared objects have java types and were thus compared with equals method
  
  field/property 'tags[0]' differ:
  - actual value  : "newsletter"
  - expected value: "vip"
  Compared objects have java types and were thus compared with equals method
  
  field/property 'tags[1]' differ:
  - actual value  : "vip"
  - expected value: "newsletter"
  Compared objects have java types and were thus compared with equals method
  
  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
everything but ignoringCollectionOrder():
  Expecting actual:
    Customer{id=99, name=Asha Patil, email=asha@example.com, address=Address[street=12 MG Road, city=Pune, postcode=411001], tags=[newsletter, 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 2 differences:
  
  field/property 'tags[0]' differ:
  - actual value  : "newsletter"
  - expected value: "vip"
  Compared objects have java types and were thus compared with equals method
  
  field/property 'tags[1]' differ:
  - actual value  : "vip"
  - expected value: "newsletter"
  Compared objects have java types and were thus compared with equals method
  
  The recursive comparison was performed with this configuration:
  - the following fields were ignored in the comparison: id, createdAt
  - 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.math.BigDecimal -> BigDecimal compared with compareTo (scale ignored)
    - 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
everything but the BigDecimal comparator:
  Expecting actual:
    Customer{id=99, name=Asha Patil, email=asha@example.com, address=Address[street=12 MG Road, city=Pune, postcode=411001], tags=[newsletter, 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 difference:
  
  field/property 'creditLimit' differ:
  - actual value  : 5000.0
  - expected value: 5000.00
  Compared objects have java types and were thus compared with equals method
  
  The recursive comparison was performed with this configuration:
  - the following fields were ignored in the comparison: id, createdAt
  - 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)
  - collection order was ignored in all fields in the comparison
  - 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