Web Dev Bros » Testing

ASP.Net MVC, Fluent Validation and testing

Dai Bok — Fri, 03 Dec 2010 15:40:58 +0000

I am finally coming to the end of a project, and I thought it would be good to write a little post on how we have managed to set up our fluent validation for our MVC project. In the start we did some research into how to go about performing validation, and found a number of recommendations. But all involved using data annotations. In this post, I will show you how I set up fluent validation, to work smoothly with my MVC 2 project. I create a custom model binder to validate view models and show how to validate a registration using fluent validation. Finally I show how to unit test the validation rules I needed for registration.

To start with, there are some problems I have with data annotations

1 – Too many annotations make your model s look ugly. Take this example .

public class Product {

public int Id { get ; set ; }

[Required]
[StringLength(10)]
public string Name { get; set; }

[Required]
public string Description { get; set; }

[DisplayName("Price")]
[Required]
[RegularExpression(@"^\$?\d+(\.(\d{2}))?$")]
public decimal UnitPrice { get; set; }
}

Now wouldn’t it be nice to have your model/entity just look like this.

public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public decimal UnitPrice { get;set; }
}

2 – Complex data validation with attributes makes your code get even more ugly. Take a lot at this example showing how to achieve slightly more complexity with data annotations. Now trying to reuse and share attributes seem to make things more and more complex….

3- I think there may be a performance issue, as we need to extract the validation attributes using reflection. Now, while these are simple models, with simple validation rules, we may not notice the performance degrading, but I am sure that with numerous complex attributes, things might run a little slow. (I need to prove this though – maybe when I get time, I will write some tests – I could be wrong here, things might change in MVC 3)

So after looking at some examples, such as xVal –dead now, Entity validation with visitors and extension methods these all did the job, but I would need to write lots of helpers, what I needed was some kind of framework for validation. Then I found fluent validation.

Linking MVC with Fluent Validation

So let us look at how we set our MVC project . Firstly, I want to automate the validation, so that any errors are automically added to the models state. With some help from Jeremy I set up an customised BindAndValidate attribute. Here is a simplified attribute we started with.

    1     public class BindAndValidateAttribute : CustomModelBinderAttribute,  IModelBinder {
    2         AttributedValidatorFactory validatorFactory = new AttributedValidatorFactory();
    3 
    4         public override IModelBinder GetBinder() {
    5             return this;
    6         }
    7 
    8         public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) {
    9 
   10             var innerBinder = new DefaultModelBinder();
   11             var boundInstance = innerBinder.BindModel(controllerContext, bindingContext);
   12             if (boundInstance != null)
   13                 ValidateInstance(boundInstance, bindingContext);
   14 
   15             return boundInstance;
   16         }
   17 
   18         void ValidateInstance(object instance, ModelBindingContext context) {
   19             var validator = validatorFactory.GetValidator(context.ModelType);
   20             if (validator != null)
   21             {
   22                 var result = validator.Validate(instance);
   23                 result.AddToModelState(context.ModelState, "");
   24             }
   25         }
   26     }

Now all I need to do is hook this up with my controller method. In the Sign in method, I add the attribute [BindAndValidatiate] and all I need to do is check that the model state is valid. If so, I perform the log in.

    1     public class AccountController : BaseController {
    2         public ActionResult Signin() {
    3             return View();
    4         }
    5 
    6         [HttpPost]
    7         public ActionResult Signin([BindAndValidate] ChangeEmailModel model) {
    8 
    9             if (ModelState.IsValid)
   10                 PerformSignIn();
   11 
   12             return View();
   13         }
   14     }

Linking MVC View Models with Fluent Validation

Lets look at how all this works. What we need to do is create out model, then create our validator. We then hook our validator to our model by adding the validator atrribute to our model. I am using a simple Register View Model here as an example.

    1     [Validator(typeof(RegisterViewModelValidator))]
    2     public class RegisterViewModel
    3     {
    4         public string Email { get; set; }
    5         public string Password { get; set; }
    6         public string ConfirmPassword { get; set; }
    7     }

Now for the model validator. Here we have some simple rules. The password must not be empty, and it must also be a good password. The password confirmation must be the same as the password, and finally the Email must be a valid email address, and also not already exisit in our site.

    1     public class RegisterViewModelValidator : AbstractValidator<RegisterViewModel> {
    2         public RegisterViewModelValidator() {
    3             RuleFor(reg => reg.Password)
    4                     .NotEmpty()
    5                     .WithMessage("Please provide a password")
    6                     .Must(BeGoodPassword)
    7                     .WithMessage("Password must be at least 8 characters long, and contain numbers and letters");
    8 
    9             RuleFor(reg => reg.ConfirmPassword)
   10                     .Equal(reg => reg.Password)
   11                     .WithMessage("Passwords do not match");
   12 
   13             RuleFor(reg => reg.Email)
   14                    .EmailAddress()
   15                    .WithMessage("Invalid Email")
   16                    .Must(BeUniqueEmail)
   17                    .WithMessage("Account already Registered");
   18         }
   19 
   20         public bool BeGoodPassword(string password) {
   21             Regex regex = new Regex(@"^.*(?=.{8,})(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).*$");
   22             return regex.IsMatch(password);
   23         }
   24 
   25         public bool BeUniqueEmail(string email) {
   26             int count = Repository.GetInstance().CountOccurrencesOfEmail(email);
   27             return (count == 0);
   28         }
   29     }

Test your validation

Now, finally for the testing, whcih is really useful, when I want to make sure that things work 100%! To keep it simepl, I am just going to test the password rule, because testing the email requires a lot more of an explination. So working from some simple examples Here: I have written three tests. Thfirst is to make sure that the password can not be null. The second is to catch a week password. The third makes sure that a strong password does not cause an error.

    1         [Test]
    2         public void Should_have_error_when_Password_is_null() {
    3             validator.ShouldHaveValidationErrorFor(reg => reg.Password, null as string);
    4         }
    5 
    6         [Test]
    7         public void Should_have_error_when_Password_is_weak() {
    8             validator.ShouldHaveValidationErrorFor(reg => reg.Password, "weakpass");
    9         }
   10 
   11         [Test]
   12         public void Should_not_have_error_when_Password_is_strong() {
   13             Validator.ShouldNotHaveValidationErrorFor(reg => reg.Password, "SecretPassword123");
   14         }

And that is it! There is quite a lot you can achieve with fluent validation, such as reusing validators on complex properties and also some useful conditions like when or unless! The reasons I like this are that it uses generics to help build clean code. There is now no need to attributes on every property I have. Also, Jeremy was also very quick to help with any questions I had. Thanks for the help Jeremy.

Testing code changes, bugfixes, new features, …

Michal — Wed, 19 Aug 2009 23:00:52 +0000

When you implement a new feature somewhere, when you change just some bits of your code, when you fix a bug, or you just change a common text in an app… What do you do afterwards? Do you really check the result or do you trust yourself that it works fine 100%. It is an interesting thing to talk about…

I have to be honest and admit that I trusted myself a lot of times in the early days and at least 2 of 10 times I was wrong. If you deal with customers then it’s two times too much. Especially when you have that guy on the phone and you claim that you did change it, but he is browsing the application and does not see any changes. In that case you’re really pissed because you haven’t spent one minute to check the result/consequence of your change.

So that’s why I always suggest to check EVERYTHING that has been changed. You never know what you forget, but when you get sure that you see the change yourself then you’re on the safe side. Here is a list what you could not have thought about:

you have been working in the wrong file. The file you have been working on was just a backup, in the wrong location, wrong server, etc. Such things happen everyday.
you forgot to refresh/restart some service, application, etc.
forgot to publish the file. This is common but i am sure it happens as well. For instance you forgot to upload the file on the server if its a web app.
forgot to compile. for all out there who need to do this.
last but not least programing failures which you haven’t thought about (especially when you are changing code of others you should 100% check the effect of the change even if it’s just a typo): you changed the wrong part of the code. Happens usually when there are duplicate pieces of code, which in turn happens because of bad programming style (think of the DRY principle).

Hence it’s highly recommended to check EVERY change. You save yourself and others a lot of troubles and iterations of changing and testing. Personally I think that this is a programmers quality characteristic and that it’s not a tall order to expect a check of the change. In most cases it’s less than a minute. Don’t get lazy …. For sure everybody does, but be aware of all the points I mentioned above.

Bulk testing your model attributes with rails

Michal — Wed, 12 Dec 2007 11:20:39 +0000

When it comes to testing in Ruby on Rails I tend to test every piece of its public interface. This means I test every single public method and attribute to ensure my desired functionality. Recently I've updated my application from Rails 1.2.5 to 2.0.1 and I was happy to have tests. None of them failed and so I knew that my application is ready to rock with the new Rails 2.0.
However, what I want to write in this article about is how to do bulk testing of each single attribute of your models. Let's be a bit precise. Say we have a model User which has attributes firstname, lastnameand age. In order to perfectly test the User model we should write tests which ...

ensure that invalid values result in an error for the tested attribute (e.g. age -2 is invalid, so the instance should hold an error for the attribute age)
and valid values don't result in an error for the tested attribute (e.g. age 20 should be fine)

Usually you should test a couple of invalid values and a couple of valid values against each attribute of your model. This can be quite a lot to code. I explain a nice approach how to speed things up and save time for the next family event.

(Code below has been tested with Rails 1.2.5 and Rails 2.0.1) Let's say our User class looks the following:

PLAIN TEXT

RUBY:

class User
validates_length_of :firstname, :in => 2..255
validates_length_of :lastname, :in => 3..255
validates_numericality_of :age, :only_integer => true
protected
def validate
errors.add(:age, "must be greater 0 and maximum 100") if age.nil? || (1..100).include?(age)
end
end

I don't go too much into detail about this. Simply: It's a User which is bound to a Users database table and includes three validations:

the firstname should have at least 2 chars and maximum 255
the firstname should have at least 3 chars and maximum 255
the age must be a number greater than 0 and maximum 100

Best case would be if we completele test the User model for the following cases (testing that wrong values fail and correct values don't fail):

valid firstnames: michal, tom, John, Jennifer K, David
invalid firstname: nil, J, ''
valid lastnames: gabrukiewicz, Aniston, Heinemeier Hansson
invalid lastnames: nil, gr, t, ''
valid ages: 1, 10, 20, 73
invalid ages: nil, '', 0, -10, -36, x, 7sz, 101, 120
creating a valid User and successfully saving (not described in this article)
get an existing user, modify some attributes and save (not described in this article))

Here we defined what is wrong and what not (what is even better: you could write this tests even before you write your User model). In order to do the bulk testing I have written a helper method which will do the stuff for us in a Rails-way. We put this method into our test_helper.rb so its available to all our test cases:

PLAIN TEXT

RUBY:

#tests ONE attribute of the tested model (@model must be set in setup method of the testcase) against given values.
#expecting: what do we expect the values to be (:valid or :invalid)
#attr: the tested attribute (provide an array if the error key differs from the attribute name)
#vals: the values you want to test against
def attr_test(expecting, attr, vals)
raise ArgumentError, 'model must be set to the testing model' if @model.blank?
key = att = attr
att, key = attr[0], attr[1] if attr.is_a? Array
vals.each do |v|
m = @model.new(att => v)
m.valid?
errors = m.errors.on(key)
if expecting == :valid
assert errors.nil?, "'#{v}' should be a valid #{att.to_s} (#{errors})"
else
assert !errors.nil?, "'#{v}' should be an invalid #{att.to_s}"
end
end
end

You see that the method expects the attribute we want to test (attr), the tested values (vals) and what we expect the values to be (expecting) - valid or invalid. Furthermore you see that the tested model is taken from the instance variable (@model) which will be taken from your individual test case (placed into the setup method). Thats to stick with DRY (cause every unit test deals with one model). Last but not least the helper asserts with a nice error message which eases us up to find the problem .. if there is one.
Ok enough, we can use this now for the test of our User. Rails generated the UserTest for us when we generated the model. We test our attributes firstname, lastname and age. All for validity and invalidity.

PLAIN TEXT

RUBY:

class UserTest
def setup
@model = User
end
def test_firstname
attr_test(:valid, :firstname, ['michal', 'tom', 'John', 'Jennifer K', 'David'])
attr_test(:invalid, :lastname, [nil, 'J', ''])
end
end

Thats nice but at this point we stop. We are not testing lastname and age anymore because before we do so we DRY this a bit up. We add another helper method which uses our existing attr_test and tests the invalid and valid values in one go. After that we sit back and watch our tests run. Bung this method into your test_helper.rb ..

PLAIN TEXT

RUBY:

#this checks valid and invalid attributes in one go.
#- check attr_test to understand more details if necessary
def bulk_attr_test(attr, values)
attr_test(:invalid, attr, values[:invalid])
attr_test(:valid, attr, values[:valid])
end

with this we are ready to rock our User class. See the full test now...

PLAIN TEXT

RUBY:

class UserTest
def setup
@model = User
end
def test_firstname
bulk_attr_test(:firstname,
:valid => ['michal', 'tom', 'John', 'Jennifer K', 'David'],
:invalid => [nil, 'J', ''])
end
def test_lastname
bulk_attr_test(:lastname,
:valid => ['gabrukiewicz', 'Aniston', 'Heinemeier Hansson'],
:invalid => [nil, 'gr', 't', ''])
end
def test_age
bulk_attr_test(:age,
:valid => [1, 10, 20, 73],
:invalid => [nil, '', 0, -10, -36, x, 7sz, 101, 120])
end
end

That's it if the tests were successful then your model is working fine. If not then you will see helpful messages in your console which will indicate what went wrong during the attributes test.

I strongly recommend you to test all your models against the functionality you will use in your application(s) (all public class members). This takes a bit of time but it let's you sleep better after doing any upgrades, enhancements, bug fixes etc. And don't forget: never cheat on yourself when writing tests! you are writing them for you ...