Skip to content
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

Fix assertions Without*** when there are multiple failures (#1937) #1938

Conversation

Aleksei-Pankratev-EPAM
Copy link
Contributor

@Aleksei-Pankratev-EPAM Aleksei-Pankratev-EPAM commented May 5, 2022

For assertions in a form of Without*** we need to use only failures that are matching to previously applied predicates (such as property name). Otherwise, we are treating failures for other properties as violating current assertion.

Example:

  • Failure 1: Name must not be empty
  • Failure 2: Surname must not be empty

results.ShouldHaveValidationErrorFor(x => x.Surname) has Failure 1 in UnmatchingFailures and Failure 2 in MatchingFailures. If we then add a predicate .WithoutErrorCode("foo") and apply it to all failures (as we did before), then Failure 1 will be considered a violation. In this PR we change WhenAll to only consider MatchingFailures - and Failure 1 does not have effect.

Similar logic applies to With*** assertions: when they are multiple failing rules and one of the expectations was not met (for ex., WithMessage specifies a wrong text) we should be using MatchingFailures to correctly display a validation messsage.

Fixes #1937

…ked correctly when there is more than one failure
@JeremySkinner
Copy link
Member

Thanks, looks good. Give me a shout once you’re happy with your additional testing and I’ll get this deployed.

@JeremySkinner JeremySkinner added this to the 11.0.1 milestone May 5, 2022
@Aleksei-Pankratev-EPAM Aleksei-Pankratev-EPAM marked this pull request as ready for review May 7, 2022 04:57
@Aleksei-Pankratev-EPAM
Copy link
Contributor Author

@JeremySkinner I think, now it's working as expected. Asymmetry in When and WhenAll bothered me, now they are consistent.

@JeremySkinner JeremySkinner merged commit eae767d into FluentValidation:main May 7, 2022
@JeremySkinner
Copy link
Member

Merged, thanks for doing this so quickly!

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.

TestHelper.ShouldHaveValidationErrorFor.WithoutErrorCode broken in 11.0
2 participants