New methods for testing validators: ShouldPass/Only

Is your feature request related to a problem? Please describe.

We are using FluentValidation quite intensively, and write lots of tests for our validators. That’s why we came up with shorter and (I want to believe) more expressive syntax for asserting the behavior of our validators.

If you agree with the approach in general, I will go ahead and create a pull request so that more people could benefit from that syntax.

The current approach for positive assertions which is used in FluentValidation itself and can be considered recommended, looks like this:

    var result = validator.Validate(validaInstance);
    result.IsValid.ShouldBeTrue();

The issue is, when the validation unexpectedly fails, this test does not give any information on what errors were raised, and we need to do manual debugging to find the reason.

For testing negative scenario, if we want to assert that only a single error was raised, we can use this approach:

    var result = validator.Validate(invalidInstance);
    result.Errors.Single().ErrorMessage.ShouldEqual("I am a bad guy!");

But again, in case of an unexpected error, there will be just Sequence contains more than one element, and we need to debug to find a culprit.

Describe the solution you’d like

What we did was to add a couple of extension methods that check if the validation succeeded, verify that error messages match the expectation (when provided), and in case of a failure, output the detailed information about which errors were expected, which unexpectedly occurred, and which did not occur though expected.

In code, it looks like this:

    validator.TestValidate(validInstance).ShouldPass();
    validator.TestValidate(invalidInstance).ShouldFail(); // Here we do not care about the exact messages
    validator.TestValidate(invalidInstance).ShouldFail("The nose is too long"); // If we expect a single message
    validator.TestValidate(invalidInstance).ShouldFail("The nose is too long", "The eyes are too square", ...); // If we expect more than one message

The latter, with multiple error messages, is not of wide use because we usually test one rule in a single test, but still this can be useful.

What this syntax does not support is verification of property names, error severity, etc. As well as it does not let you specify “I need to check that this error is raised, but there may be more, I don’t care”. But for this, the existing methods (ShouldHaveValidationErrorFor and similar) work perfectly, we are not proposing to do anything with them.

Describe alternatives you’ve considered

Initially, we used the approach very similar to what is used within FluentValidation for unit tests, but then switched to this new syntax as it is shorter and, well, more Fluent.

Additional Context

No response

[JeremySkinner]

Sounds good, thanks! I’m away on holiday from Friday and will be unavailable for a couple of weeks, but will do my best to review when I’m back

[JeremySkinner]

Merged for 11.0 release