I have been lucky over the past two years. I have had the opportunity to use Cucumber as a testing tool in several environments. I have worked on four web applications – one written in Groovy, one in PHP, and two in Java. I worked with a team developing a batch application. I worked with a team that was building Informatica transformations and I worked with a team developing an iPhone application. Even though each environment was quite different, cucumber worked as an amazing tool to implement Acceptance Test Driven Development in each case.

The most interesting thing about using Cucumber in such diverse environments is that I started to see similar patterns each time. In the first, second, and third post in this series we discussed the Page Object pattern. In this posting I will talk briefly about how this pattern applies to other environments. I will also talk about another pattern I discovered. I call it the Default Data pattern. Finally I will also talk about building high level Scenarios that express details only where necessary.

Continue reading →

In the first and second posts of this series we introduced Page Objects and evolved them to include page partials and return the next page object. In this post we will introduce a simple domain specific language that will eliminate a lot of the annoying repetitive work we have done so far. After we look at the DSL we will refactor our tests to take advantage of its’ capabilities. When we are finished our scripts will be cleaner than when we left off at the end of the last post.

Continue reading →

In the first post in this series I introduced the Page Object. If you haven’t done so I would suggest you read the first post as we will be building on it in this post. If you want to follow along with the code you can download this zip file that has the code where we left off last time.

In this second post I will introduce two simple concepts that will make our scripts more robust. We will apply one of these enhancements to our scripts taking us further down the path of creating tests that are not brittle. But first we will add one more scenario to our cukes.

Continue reading →

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.

Continue reading →