Debugging fluent validation rules

Question

The problem

I'm struggling to make my Fluent Validation RuleSet work, currently it doesn't, and I don't have any idea why is that happening, everything seems all right. I would like to somehow step into the code that performs the validation itself, but RuleSet lambdas are ExpressionTrees which doesn't provide even poor debugging experience.

The question

Is there a way to debug RuleSet logic to see what's happening inside RuleSets?

Mcbryde

Answer 1

FluentValidation is open source, so theoretically you could download the code from the repo at https://github.com/JeremySkinner/FluentValidation and then load up the solution, reference it directly, then step through.

Hopefully this will get you where you need to be, but I'm sure someone here could help if you provided your rules and maybe some unit tests that show the failures.

Marni

The problem seems like isn't related to the rule sets themselves because the rules are getting executed (I see that via debugger), and even when I add faulty rules that should fail with 100% guarantee, they aren't failing... – Mcbryde

Answer 2

The current version of FluentValidation allows you to unit test your validators by using the TestValidate extension method. There is also an async version available.

Calling this method, passing an object to validate, will return a TestValidationResult<> object which has 2 useful methods ShouldHaveValidationErrorFor and ShouldNotHaveValidationErrorFor that can be used to check if tests passed or failed.

The documentation can be found here https://docs.fluentvalidation.net/en/latest/testing.html

Ayurveda

Answer 3

You can debug Fluent Validation a little bit. When the validator is injected you can debug into the constructor like this:

At least then you know your services are registered in DI.

If you have a Custom validator, you can put a breakpoint there as well and actually break when the validation is called.

RuleFor(x => x.InstallLocation.Address.StreetAddress)
    .NotEmpty()
    .Custom(InstalledAtPhysicalStreetAddress);

Wolfgang

@Lu4, I think that since this answers your question most directly (the others offer workarounds), it should be the accepted answer. – Antichrist

Answer 4

Tip: Passing in the instance you're validating can be quite helpful (or required sometimes). In your validator class constructor:

public MyTextClassValidator(MyTextClass myTextClass)
{
    RuleFor(x => x.Text)
    .MaximumLength(myTextClass.MaximumLength)
    .WithMessage("Too Long");
}

If you set a breakpoint on a rule, you can make sure the instance being validated contains what is expected.

--- OR ---

If you have ReSharper:

1. Open your validator file that has the class that inherits from AbstractValidator.
2. Right-click on AbstractValidator and Go To Definition (F12). ReSharper will decompile it.
3. In the decompiled class, find your method call and add a breakpoint. For example, add a breakpoint in public Task<ValidationResult> ValidateAsync(T instance, CancellationToken cancellation = new())
4. Start debugging.
5. Ensure the symbols are loaded for FluentValidation.dll
   • Debug Menu -> Windows -> Modules
   • Search for FluentValidation.dll
   • Right-click on it and select Load Symbols with ReSharper Decompiler

Castroprauxel

Answer 5

There is no way to debug Fluent Validator code with Visual Studio tools. You need to comment the specific part of code (RuleFor) that you want to test. Keep doing it until all rules are tested.

Broeker

This is actually incorrect. Jess's answer illustrates ways that FluentValidators can be debugged, and I know it's correct because I'm doing it now. – Antichrist