On a new ASP.NET MVC application we are following a TDD approach, using NUnit for unit testing and Unity for Dependancy Injection.
Our views are being made as "dumb" as possible by adjusting our models to supply data in the most appropriate fashion for our views.
Is there a merit in unit testing our views? If so - how?
I'm not (yet) familiar with ASP.net MVC in particular, but I have a good knowledge of the MVC pattern. Generally I would say that you don't gain much more by testing your view. By using the MVC approach most (if not all) your domain logic resides inside your controller classes and the business logic in your business/service layer classes. So unit-testing your service layer should guarantee that your business logic is satisfied (which is the main goal). Investigating further testing of your controllers (with mock objects for Http requests if you need) guarantees that your domain logic is fine.
So unit testing your views doesn't sound to me to give your more benefits. I've heard about view testing just in relationship with recorders (or similar frameworks) which simulate user clicks on the UI etc...
The advantage of the MVC pattern is that views are supposed to be very lightweight and contain no code that needs to be tested.
If a view does contain code that needs to be tested, it should be moved out into the controller or model and unit tested there.
I was just reading a good article by Justin Etheredge earlier this week regarding ASP.NET MVC testing.
Here's the link: Building Testable ASP.NET MVC Applications
Justin does indeed address the testing of views in a small "sidebar" section of the article and states the following:
ASP.NET MVC Code-Behind Pages
If you were following ASP.NET MVC before the final release, you may have noticed that the code-behind pages have been removed from the framework. These pages served no functionality in the ASP.NET MVC framework and promoted putting logic into views, where it does not belong. Any logic contained in views is difficult to test in much the same way that code-behind files in ASP.NET Web Forms are difficult to test.
I tend to agree with this in that I would consider logic inside a "view" to be something of a "smell" and, personally, I'd be looking for a way to remove such logic and place it inside the controller or the model where it's much easier to test.
The nice thing about the MVC pattern is that you are able to unit test far more of the UI layer than other patterns (or anti-patterns). However, testing the views really can't be done as a unit test because it would require an external dependency (like a browser).
This doesn't mean you shouldn't test views, it just means that you can't unit test views. Functional/integrations tests are still a good idea.