When you’re bringing a legacy system under test, you often don’t want to mess with things that already work: it’s more important to get some decent coverage. Once you have that, you can go back and make improvements.
That means that even though EqualsVerifier might fail on some (or many) of your classes, you don’t want to change their
equals methods just yet, because some part of the codebase might depend on that faulty implementation. At the same time, you do want to use EqualsVerifier, because you want to increase test coverage.
For these situations, there are several types of warnings that you can suppress:
Warning.ALL_FIELDS_SHOULD_BE_USED: disables what it says it disables. You can be more specific with the methods
withOnlyTheseFields. Read more about this topic on the page about ignoring fields.
Warning.IDENTICAL_COPY_FOR_VERSIONED_ENTITY: allows the behavior in JPA where
equalsbehaves differently when the id is set than when it is not set. Read more about this topic on the page about JPA entities.
Warning.INHERITED_DIRECTLY_FROM_OBJECT: disables the check that the class actually overrides
equals. This can be useful when you scan a whole package or directory for classes and call EqualsVerifier in bulk.
Warning.NONFINAL_FIELDS: disables the check that all fields are final. You can read more about this topic on the page about final fields.
Warning.NULL_FIELDS: disables the check that all
hashCodemethods have a null-check for non-primitive fields. You can be more specific with the method
withNonnullFields. Read more about this topic on the page about null.
equalsmethods to use
equalson non-primitive fields.
Warning.STRICT_HASHCODE: disables the check that all fields used in
equalsmust also be used in
Warning.STRICT_INHERITANCE: disables the check that classes or their
equalsmethods be final, or that inheritance is properly accounted for. Read more about this topic on the page about inheritance.
Warning.TRANSIENT_FIELDS: disables the check that transient fields do not participate in
equals. This applies both to Java’s
transientkeyword, which applies to serialization, and to JPA’s
@Transientannotation, which applies to, well, JPA.
Of course, once you have sufficient test coverage, you will come back and fix these issues, right? 😉