Comment Feed for Channel 9 - Testing ASP.NET MVC Views, from New Project to the Build Server http://media.ch9.ms/ch9/5bd5/f9a81944-dff0-4279-a1e3-fc3bf5935bd5/aspConfTestingMvcViews_220.jpg Channel 9 - Testing ASP.NET MVC Views, from New Project to the Build Server en Mon, 20 May 2013 08:23:33 GMT Mon, 20 May 2013 08:23:33 GMT Rev9 Re: Testing ASP.NET MVC Views, from New Project to the Build Server The session shows a way to test your views (and only your views). The approach seems a bit fragile though.

posted by BennyM

]]> http://channel9.msdn.com/Events/aspConf/aspConf/Testing-ASP-NET-MVC-Views-from-New-Project-to-the-Build-Server#c634785690857468126 Sun, 22 Jul 2012 15:51:25 GMT http://channel9.msdn.com/Events/aspConf/aspConf/Testing-ASP-NET-MVC-Views-from-New-Project-to-the-Build-Server#c634785690857468126 BennyM Re: Testing ASP.NET MVC Views, from New Project to the Build Server Certainly there are aspects of testing views that are less than ideal.

To me the ideal workflow would be something like this.

// Instantiate ViewEngine

// Render a view to a string by providing a path to a template and an in-memory model

// Verify.

But that's not the world we live in, so Llewellyn (@llewellynfalco) and Henrik (@henebb) found another way.  

When someone says an approach is fragile, and we're talking about testing, to me that means the test fails when it shouldn't--reacting to changes in the environment that I don't care about.  We've found some ways to resolve some of these sources of fragility.  For example, we resolved the problem caused by specifying a relative path when starting up CassiniDev.  The exact location of the webapp on the disk is not something I care about, so that was fragility and we resolved it.  

Some parts remain fragile, like the problem with port numbers.  I don't care about the port number, but it makes my test break when I change it.  After the talk, Llewellyn and I brainstromed some ideas for resolving the problem with ports, but its too early to say if any of those ideas will pan out.

I'd like to know some specific areas you found fragile and if you had any ideas about resolving them.  Testing Views isn't pretty, but I know of at least three teams using this approach in production, and we're all pretty happy with the results.  The day to day "practical" fragility is not as high as one might think after watching a 1 hour demo.

posted by Magnifico

]]> http://channel9.msdn.com/Events/aspConf/aspConf/Testing-ASP-NET-MVC-Views-from-New-Project-to-the-Build-Server#c634785725306918959 Sun, 22 Jul 2012 16:48:50 GMT http://channel9.msdn.com/Events/aspConf/aspConf/Testing-ASP-NET-MVC-Views-from-New-Project-to-the-Build-Server#c634785725306918959 Magnifico Re: Testing ASP.NET MVC Views, from New Project to the Build Server Here are a couple follow up notes about getting the project to work on the build server.  

  • First, the "ambiguous branch" issue blocking the checkout resolved itself at some point.  But I never noticed that during the demo because...
  • I forgot to enable package restore when setting up the project.  The .gitignore file was configured to ignore the /packages folder, I should have turned on package restore.  Once I turned the feature on, the project compiled normally and passed its tests.  The last check-in on the Demo branch includes this fix. https://github.com/jamesrcounts/aspConf-demo

posted by Magnifico

]]> http://channel9.msdn.com/Events/aspConf/aspConf/Testing-ASP-NET-MVC-Views-from-New-Project-to-the-Build-Server#c634789197513204779 Thu, 26 Jul 2012 17:15:51 GMT http://channel9.msdn.com/Events/aspConf/aspConf/Testing-ASP-NET-MVC-Views-from-New-Project-to-the-Build-Server#c634789197513204779 Magnifico