-
-
Notifications
You must be signed in to change notification settings - Fork 683
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
satisfiesExactlyInAnyOrder
fails if actual
overrides equals
#3339
Comments
satisfiesExactlyInAnyOrde
r due to usages of equals
and hashCode
in the implementationsatisfiesExactlyInAnyOrder
due to usages of equals
and hashCode
in the implementation
Thank you for reporting it, @PBoddington! |
satisfiesExactlyInAnyOrder
due to usages of equals
and hashCode
in the implementationsatisfiesExactlyInAnyOrder
fails if actual
overrides equals
Do you have any specific examples in mind? |
Thanks for fixing so quickly!
One other thing was #3340 but it's hard to give other specific examples right now. This came about because as an experiment to see if people in our org were writing code relying on undocumented |
Thanks, Paul! @joel-costigliola is already looking at #3340. I couldn't spot any other obvious case where the same mistake happened but we'll keep an eye on it. |
equals
andhashCode
are used in the implementation ofsatisfiesExactlyInAnyOrder
(when they definitely aren't needed). This can result in incorrect assertion results.Example of the issue:
This test fails with
but should pass.
The problem is that the use of
List::remove
in the implementation results in the wrong element being removed.In general we believe there are a number of bugs in assertj due to unnecessary usages of
equals
andhashCode
, and think that the best way to weed them out is to have unit tests using classes whereequals
andhashCode
throw exceptions.The text was updated successfully, but these errors were encountered: