Posts Tagged ‘Qunit’

Razor – Unit Testing Your Views in MVC2 with QUnit

Monday, July 19th, 2010

Ok this is a bit of a follow up from my earlier blog about the newly announced MVC view engine Razor from Scot Guthries blog a couple of  weeks ago. Below is a quote that Scott has made in the comments to the original post.

“The Razor parser and view engine can be instantiated and used outside of the ASP.NET application domain.  This means you can directly instantiate and use it within a unit test project without any dependencies on running ASP.NET.

From a unit testing perspective you can indicate the view template you want to run, supply it with any dependencies, and then pass your own test models/viewmodels to it and have it run and render back a string to you. You could then verify that the correct content came back.  This would isolate the views from your controllers and any data access, and allow you to also isolate them from the runtime environment.  View engines in ASP.NET MVC VNext (both Razor and the .ASPX one) will also support and integrate with dependency injection as well.”

Let’s start with talking about the current testing story with the current MVC framework. Now clearly you want to put as much logic into your controller as possible which is currently testable with the current MVC framework. But on the  modern MVC websites that I’ve been working on there ends up being a considerable amount of JQuery in most pages.

This is where I hear you shout “but what about QUnit you can test your JQuery with that”  Yes you can but do I do it..No I don’t.  I never really got QUnit it always seemed great in theory but in reality it seemed like too much work to implement.

Let me elaborate. All the examples I could find when I was starting out with QUnit involved testing some JavaScript discreet function that did some work and returned a value.  For example a function that added two numbers together and gave you the total back. QUnit works really well for that kind of thing. However I don’t find myself writing much of that kind of  logic in JQuery when I am using MVC. I know its possible to do it in JQuery but most of the time I try to push that kind of logic back into the .NET world and onto the server  where it belongs rather than in the browser.

So typically I find myself writing JQuery that does fairly trivial stuff. Hiding and showing stuff and manipulating items in the Dom. Now when I say trivial it is still important. If you hide your submit button when it should be displayed you have broken your page.

Now it is possible to test this logic with QUnit, but for each test or  group of tests  you had recreate the HTML for your page or part of your page to test your JavaScript against. It is this that always seemed a bit lame to me. You were never really testing against your view proper but a mock up of your view.  Not only is it a lot more work to write your tests initially but there is a lot more maintenance work to do going forward. Any change to your HTML mark up in your view needs to be replicated across your test HTML.  Now I know you have to do maintenance with your .NET tests but most of the time we have compile-time checking. If you change the name a property on a class and you don’t update your unit test it won’t compile. Change the name of a div in your mark up and forget to implement that in your test HTML and there is nothing to tell you that there is a mismatch.

To counter this John Teague over at Los Techies outlines a technique that you can use to generate your markup automatically. To be honest I haven’t used this approach as it still seems like a lot of extra hard work, but it’s worth considering.

Therefore going back to Scott Guthrie’s  comment that we will now be able to  isolate the view from the controller pass in some data and render back a screen  as HTML. This is just fantastic, and for me the last piece in the puzzle with regards to testing. With this functionality it will should be relatively trivial to produce the markup that we can run our QUnit tests against and it means that we are actually testing our view rather than a mock up of it.

Well done Microsoft I think this is a positive step, and I can’t wait to get my hands on the framework. Keep up the good work.