Blog An exploration of the art and
craft of software development

View Specs

Posted by Marty Haught on Tuesday, October 14, 2008

I’ve had some conversations lately with the developers on one of my projects about test driven development. As this is a new concept for some of them, we get into discussing the approach. As I have been practicing TDD since 2004 it’s natural for me. Covering model and controller specs have been easy as the benefits are clearly visible. While I won’t discuss the specifics of that sort of testing, I do want to reflect on view testing as that feels different to me.

What I’ve seen and heard as I’ve worked with other developers is that their testing in the view layer is the weakest of all. This makes sense as testing here actually offers you the least confidence that it’s doing what it needs to do. For example, you can’t sufficiently test that your html, css and js will actually produce a pleasing result to the eye. How do you write a spec that proves some element of the page appears where it should, visually? Yes, you can test the nested structure and organization of html but it means very little to how it will appear. If you get to the level of detail with your html testing, you’ll create very brittle tests that will cause great pain when you move to refactor the html. Additionally, what value do you really get from test this? No, it’s very understandable why many do not test this layer extensively.

As we speak about TDD, it becomes a bit harder to ‘sell’. It’s not difficult to conceptualize what you want to put on the page but I haven’t seen any test on this high level. Let’s say you want to create a traditional index page. You expect that the controller will provide an array of resources. Next you can describe what fields you want to see. But how do you then test that it does this? Are you just going to test that the text representations of the resources are on the page? Do you test that a name field is inside a table cell with a column labeled name? What if you are not using tables? This all assumes that some design firm hasn’t already provided the html to you. If they have this makes it easier but it doesn’t necessarily eliminate the issue of writing an effective test first. Take another example of a more complex interface like either provide in place editing on your fields or perhaps a floating div edit form if you click ‘pencil’ icon. How do you test for this unless you know it’s html structure?

What I have found works best for me is to suspend the notion that I must write a meaningful test first and instead prototype out the html so that it looks and interacts as I like. From there I can move into writing the specs.

This is the other part that I would like to touch on briefly is how you determine what you need to test. For me this comes down to a matter of time and what you consider is at risk to fail. Layout and visual concerns do not get tested on most of my projects. Instead I look at anything that is dynamic. I also don’t care to test that every single field is being rendered to the page. I know some do this and there can be some value to it but in my experience you get diminishing returns when you test to such detail. More importantly to me any sort of functionality, like forms or interactive pieces need to be tested. Right now anything that is javascript-based is not easily tested though with something such as Selenium you can cover much of it.

That brings me to my final point of how view specs and acceptance tests mix. If you have a full Selenium suite on your application how much should you really invest into your view specs? If you have a tight deadline do you need to maintain both? If you really analyze the gain of investing development time into testing this layer do you really get your money’s worth? I feel very comfortable with model and controller testing that you do, hands down. Both view and acceptance testing, I’m not sure.

blog comments powered by Disqus