As I have mentioned many times before, I’m a big adherent of unit testing. If you have a comprehensive suite of unit tests, seeing them all work before you commit a bug fix or feature to an application provides at least basic assurance that you haven’t screwed things up too badly. In the case of Web applications, the utopian goal is to be able to run your unit tests and feel assured that your application works without doing any testing through the browser at all.
There are many reasons why we’ll never see utopia, including client-side scripts and other problems related to display rather than basic input and output. However, it’s very difficult to consistently test an entire application going through it by hand using a browser, so you need to have a certain level of confidence in your unit tests. What I’ve found lately is that there’s a specific area where my unit tests usually fall short, and that’s in wiring forms up to actions in my application.
If you think of an application as an API, you can think of a URL as a method or function name, and its parameters as arguments. For example
/search.cgi may take parameters like
language. When you write a unit test for this code, you use a test harness that pretends to post to that URL, and passes in the required parameters. If the call produces the output you expect, the test is successful. What my tests often lack, though, is a guarantee that the pages that submit to that URL use the correct parameters. There are three places where the parameters are referenced: the code itself (in
search.cgi), the test, and the view that calls the URL. The view layer oftentimes goes untested.
So say someone wants to change the name of the
terms parameter to
query. They update the CGI program and the unit tests for it, and they update every page they can think of that calls
search.cgi to update the parameter name. Most of the time, there are no unit tests that verify that the parameter names are correct in forms throughout the application, and even if you wanted to write such tests, there’s no good way to make sure that those parameter names are properly checked, since they live in the middle of freeform data. Your code coverage tool isn’t going to tell you that you missed a search form on some web page in the application.
Anyone know of a good approach for this problem? It’s been giving me fits lately.