assertj: AssertJ 3.27.7 lab (soft assertions, recursive comparison, custom and generated assertions)

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01CifR2BE7PBvRy5hT8TS9oz
This commit is contained in:
2026-10-26 01:57:10 +00:00
co-authored by Claude Sonnet 5.5
parent 08e063d22e
commit 9d89323864
50 changed files with 1427 additions and 0 deletions
+89
View File
@@ -0,0 +1,89 @@
no knobs:
Expecting actual:
Customer{id=99, name=Asha Patil, [email protected], 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 protected], 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 protected], 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 protected], 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 protected], 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 protected], 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