This past week on the cucumber list Aslak asked if people knew about and where using Transforms. Based on the response I would have to say that not many know about it. I have to put myself in this category. I decided to dig in and here is what I’ve learned.
I’m releasing another chapter of my book. It is the chapter we focus on using a database in our tests. The chapter uses ActiveRecord and several additional gems. Please give it a read and let me know what you think.
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.
I am a tester on the Extremely Cheezy team. Our team is building a revolutionary new online bookstore application called depot. It is Friday afternoon and our new Iteration begins on Monday. The user-facing portion of the application is nearly finished. All that remains is the checkout page. This is my story.
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.
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:
- Introducing the concept of Page Objects
- Using modules to represent partial pages and having Page Objects return Page Objects
- The introduction of a simple DSL to make page objects easier to write
- Writing high-level tests and providing default data
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?
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.
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.
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.
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.