Can you test a razor view on its own without the need for integration testing?

Question

I've got an MVC website with many different steps a user has to take to get through it. There are validation check and timed sections (for legal requirements). Having to do an integration test each time I need to test a small change to a page is a real headache. Ideally I want to know if there is a way (maybe a plugin?) that will allow me to right click a view, somehow specify a fake model object and open it directly?

What I am ultimately looking to test is how any new client side scripting (which combines razor/javascript/jQuery) looks and works on a variety of browsers. This isn't about testing functionality of my controllers.

Answer 1

Design time data

Design time data is commonly used in WPF, there is an article here that describes a techinque for showing design time data in MVC:

http://blog.dezfowler.com/2010/11/adding-design-mode-to-your-mvc-app.html

This should provide you a method to "somehow specify a fake model object and open it directly".

That might be all you're after, or:

cURL

Can be used with real time or design time data as above.

I use cURL executed from batch files and output the content to a number of files.

For example, this batch might simulate logging on:

Logon.bat:

echo Index without logon
curl http://localhost/index.html
echo Logon
curl http://localhost/login.html --data "username=a&password=p" ---dump-header auth.txt
echo Index after logon
curl http://localhost/index.html --cookie auth.txt

RunAll.bat:

call Logon.bat > logon_result.txt

The first time I run it, I also manually review the pages in a browser, then I know I can commit these batch result files (such as logon_result.txt) as the expected output.

Subsequent times I run the batch files, any changes are highlighted in revision control. At this point I review the differences and either OK them, and commit as the new expected output. Or I fix a bug.

I usually use this for WebAPI integration testing, but it should work for any http served page. One specific scenario to bare in mind is that for sweeping changes to a shared layout for example, you may not want to check them all manually. So make sure everything is checked and commited before the layout change, then little bugs won't be hidden within a vast number of changes.

I've caught some bad bugs with this techinque. Ever put an System.Web.Mvc.AuthorizeAttribute on a ApiController instead of an System.Web.Http.AuthorizeAttribute? Doesn't block unauthorized users, but code looks fine.

You may want to also set up a new clean database or restore a snapshot of one as the first task of the RunAll.bat file, so that any data displayed on pages is the same each run and doesn't show as a change.