Testing ASP.NET MVC Views, from New Project to the Build Server

Play Testing ASP.NET MVC Views, from New Project to the Build Server

The Discussion

  • User profile image

    The session shows a way to test your views (and only your views). The approach seems a bit fragile though.

  • User profile image

    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.

  • User profile image

    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

Add Your 2 Cents