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.
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.
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.