There has been a lot of talk about the value of tests that drive the user interface. Some people in the industry that I have a lot of respect for have gone as far as to say that you should not create these type of tests. You should instead create tests that access the application code directly under the UI. Part of their reasoning is that tests that hit the UI are brittle and therefore high maintenance.
And yet UI tests are very valuable. When a user describes the behavior of a system they usually do so in terms of the user interface. Also, acceptance tests that provide examples of behavior for a story almost always present this behavior from the end users point of view.
This post is the first in a series that will describe the techniques I use to make my UI tests agile. These techniques have been developed while coaching teams in very diverse technologies and platforms and as a result are “field tested”. The tools I will use for all of the examples are ruby and cucumber.
