Closed Alexis2004 closed 4 years ago
AbstractList
has a very specialized and optimized implementation that is extremely hard to verify directly. The same applies to any of its subclasses. I've tried several times to make it work, but it's just not feasible, unfortunately.
As a workaround you could change your DTO to contain ArrayList
instead of overriding it. Comosition over inheritance, right? 😉
I'll see if I can make EqualsVerifier emit a more helpful error message in this situation.
It's a good idea to use composition instead of inheritance in new code. Unfortunately, I'm trying to introduce unit testing for some legacy DTOs in the project and that DTO is part of the Hibernate entity that have a lot of saved data in production databases. So I will have to implement additional type adapters for each entity to save the current data format, and this doesn't look like an easy task.
So I'm wondering if it is possible to implement special behavior for cloning successors of ArrayList
collection? For example, we can try to instantiate a new instance of TestDTO
using a parameterless constructor and then adding to it duplicates of all items from source collection using the addAll
method. If it's impossible to implement it automatically it would be great to give a manual handle to control the instantiation of problematic classes like this (something similar to withPrefabValues
configuration option).
Ah, I see.
Instantiating objects isn't the problem, EqualsVerifier can do that just fine. The issue is that EqualsVerifier will use reflection to change fields and see what happens. This is fine for POJO's, but AbstractList
has complicated internal invariants that get screwed up this way. Unfortunately, this is how EqualsVerifier works. There are other ways of course, but those would probably require an (almost) complete re-write of EqualsVerifier. That requires an amount of time that I simply do not have, unfortunately.
Oops, accidentally closed this. I still want to implement a better error message.
I've released version 3.4.3, which contains a more helpful error message.
What steps will reproduce the problem?
Verify any class that extends ArrayList collection.
What is the code that triggers this problem?
What error message or stack trace does EqualsVerifier give?
What did you expect?
I expect that my DTO can be verified by EqualsVerifier.
Which version of EqualsVerifier are you using?
Latest version 3.4.2
Please provide any additional information below.
It seems that EqualsVerifier library is trying to duplicate object in some strange way that break ArrayList internals integrity.