My Book

For the past two of years I have had a string of successes and a lot of fun helping teams adopt Acceptance Test Driven Development with Cucumber. I was never brought in to do this specifically. You see, I am an agile coach and I help team adopt agile and lean practices. And yet due to these successes with Cucumber I started thinking about how I might share these experiences.

I initially decided I would write a blog series. When I outlined it I quickly determined it would take nearly thirty entries to share all I wanted to share. That was when I came up with the crazy idea of writing a book. I had no idea what I was getting myself into. For the past several months I have spent a fair amount of my free time (do I really have free time?) working on this book. With this post I am releasing the first two chapters of that book.

Continue reading

Working with Cucumber on the Windows platform

Frequently I teach classes on Cucumber for individuals in the testing community. Often this is their first exposure to Ruby and Cucumber and they usually have laptops running Windows. A week before the class I send out a document detailing software to install prior to their arrival. Nearly every time somebody has difficulties installing or verifying the installation of these tools. This post is designed to help people in a similar situation with step by step instructions on getting Cucumber running on your Windows computer.

Continue reading

UI Tests – putting it all together

I have really enjoyed writing this series on UI Tests with Cucumber. I have been able to share the things I have learned while working with diverse teams helping them adopt an Acceptance Test Driven approach to deliver quality software. So far in this series we have covered:

This post is about workflow. How does automated acceptance testing fit into the software development lifecycle? Who is impacted and how? Who should run the tests and when?

Continue reading

UI Tests – Default Data

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

UI Tests – Introducing a simple DSL

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

UI Tests – Part Two

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

UI Tests – How do we keep them from being brittle?

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