Is it bad practice to unit test that a class uses a specific validation class for entity validation?

Question

I run all my actions through classes that I call "commands". To illustrate this, to create a new user I would call the following code

new CreateUserCommand(unitOfWork).SetName("Username").SetPassword("Blah").Execute();

I am now currently looking at implementing validation into this system, to validate things such as the password is a certain length, the username is not a duplicate in the database, etc...

To handle this, I am looking at using fluent validations and creating a validation class for each type of entity validation entity I want. For example, I would have a class such as

public class NewUserValidation : ValidationFor<User>
{
   public NewUserValidation() 
   {
     // Validation Rules here
   }
}

One advantage of creating validation in it's own class is that I can use the same validation rules for multiple commands (for example, editing and creating companies may use the same validation rules).

Now each of these validation classes would have unit tests associated with them. However, I am trying to figure out how to deal with the unit tests for the command classes that utilize these validation classes.

For example, when creating a test for the command class, would I create individual tests for each validation rule for the class (thus essentially duplicating all the unit tests for the validation class itself for every command class I plan to use the same validation class for)? This makes a lot of overhead, especially when I already know that the validation class works because of separate unit tests for them.

The only other option that I see is to expose a public property in the command that holds the validation class, and I would then unit test that the command's validation class is the expected validation class. The problem with this method though is I need to devise some way to verify that my Execute() method is actually running the validation class (otherwise there is no way to know if validation isn't being run).

I am still leaning towards the latter testing method, just to help keep the overhead down, but I do need to find a solution for checking if the validation is actually run. Would this be a bad way to go about it, and would I be better going for the former style instead?

Edit: To reply to both answers below, the validation is going to be used inside of the Execute() method, by a validator.Validate(entity) call in the implementation of Execute().

While I don't want to violate DRY, I don't see an easy way to verify that Execute() 1) uses the correct validation class by default and 2) Actually calls the .validate(entity) method of the validation class.

I can solve #1 by instantiating the validation class in the constructor, and expose it through a public property of the command class, but I am unsure of how to correctly unit test for the 2nd issue without repeating the individual validation unit tests.

score 2 · Accepted Answer · edited May 23 '17 at 12:04

2

You already test the functionality of the validator classes. So the only thing to test on these command classes is that they actually employ the validator.

Since how you plan to make use of these validators is not obvious, it is hard to say how this can be done. Replicating the test cases for each command is the least efficient way to go about it, but in the end, it may prove to be the only way to test the presence of validators.

EDIT: From your recent addition, this looks like a perfect candidate for using mock objects.

To test the Execute method, you can mock your validators, and verify that their validate methods are called. To test the command construction, you can mock your command object, and check that the appropriate validators are passed to it.

You may want to check out this question (stackoverflow.com). You may need to massage your design so that you can use a mock framework, though.

EDIT: Also have a look at this question (stackoverflow.com). It seems to address your requirements. The Microsoft tool Moles (microsoft.com) looks very interesting.

edited May 23 '17 at 12:04

Community

1
1

answered Mar 22 '11 at 02:22

vhallac

13,301
3
25
36

Ok I see what you mean! My design will need to be changed a bit, but how do you suggest I allow unit tests to pass in a validation class? The issue that I see is that unit tests will have to modify the validation class of a command (to give it a mocked one), but outside of unit tests the validation object should never be changed (it should be managed by the command class itself, otherwise there's no guarantee at run-time that something didn't change the validation unexpectedly). – KallDrexx Mar 22 '11 at 12:34
@KallDrexx The validators are the easy case. What you are testing is: "is my Execute() method calling all registered validators?". So, your test code would look like `new CreateUserCommand().addValidator(mockVld1).addValidator(mockVld2).Execute()`, followed by validation of both mock validators' `validate()` method being called. I am more worried about the mock command case, because more than likely, you have a method that constructs the object on the fly, and not accept it from outside. The test case is: "Is function `foobar` creating a user object and adds validators x, y, z to it?". – vhallac Mar 22 '11 at 13:16
Ok I see what you are saying, that makes sense. Thanks a lot, I'll play with this tonight. As a side note, that Pex system looks awesome, and the Pex for fun is quite entertaining to play with :) – KallDrexx Mar 22 '11 at 14:39

score 1 · Answer 2 · answered Mar 22 '11 at 02:23

You almost never want to violate DRY so I think repeating the unit tests per referencing class is absolutely wrong. I don't really understand your concern about verifying that the Execute method is running the validation class. Shouldn't that be a unit test of the Execute method? And once you tested this, why would you need to test it specifically for each type of validation class?

Finally, I'm not sure why you would need to "test that the command's validation class is the expected validation class." It sounds like you are testing a factory instead of the actual Command class.

I would only unit test things that the Command class is directly responsible for. If the Command class creates it's own validation classes that it references, then you could unit test that, I suppose. But based on the information you've provided, it really doesn't sound right.

Agreed re: testing a factory. If you're testing that the correct validator object is selected, you need to write unit tests for whatever factory object is responsible for doing that. If your Command objects are responsible for creating their own validator, consider seperating that out — MattDavey, Mar 22 '11 at 09:03

score 0 · Answer 3 · answered Mar 22 '11 at 08:26

If i were you i whould create only one validationFalingTest where you execute one command with invalid data.

This test enshures that the command has a working validation. In my opinion verifying if there is correct instance of a verification class is to much implementation specific.

Is it bad practice to unit test that a class uses a specific validation class for entity validation?

3 Answers3