I’m happy to announce that my book is finally available. I’m publishing it through LeanPub and the version that is released is a beta. This means that I will be publishing updates every few weeks until a the final book is complete.
You can get your copy on the LeanPub site. I hope you enjoy the 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.
A month ago I was working with a team that had a need to write acceptance tests for a feature that included drag-and-drop. My initial search turned up some code that implemented it well. I have since tried to find that code again with no success so I am sorry for not being able to give credit where it is due. Anyway, I enhanced the code I originally found and wish to present it here.
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.