Skip to content

fix list type in 2.5.13 #178

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

Closed
wants to merge 2 commits into from

Conversation

TrueJacobG
Copy link
Contributor

people list is not used, doctors list needs to have type List, because of the type checking

@scordio scordio self-assigned this May 18, 2025
@scordio
Copy link
Member

scordio commented May 18, 2025

Thanks for pointing this out, @TrueJacobG!

Following the semantics in the example comments, the contains parameter should have been people:

// assertion succeeds as both lists contains equivalent items in order.
assertThat(doctors).usingRecursiveFieldByFieldElementComparator(configuration)
                   .contains(sheldon); // FIXME should be the people list

// assertion fails because leonard names are different.
leonard.setName("Leonard Ofstater");
assertThat(doctors).usingRecursiveFieldByFieldElementComparator(configuration)
                   .contains(leonard); // FIXME should be the people list

// assertion fails because howard is missing and leonard is not expected.
people = list(howard, sheldon, raj)
assertThat(doctors).usingRecursiveFieldByFieldElementComparator(configuration)
                   .contains(howard); // FIXME should be the people list

However, it's not as simple as that since type checking kicks in.

For reference, the usingRecursiveFieldByFieldElementComparator Javadoc is also incorrect.

In light of this, I'm closing this PR in favor of assertj/assertj#3837.

@scordio scordio closed this May 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants