Always Read the Label: Getting the Most from Your Tools

Just the other day while doing the dishes, I came across a cheese slicer with chunks of carrot stuck in it. It looked like someone had thought it was a peeler but soon found out that the blade was not sharp enough peel a carrot. It got me thinking about tools that I had used inappropriately, but because I’m a developer, I didn’t think of kitchen tools or hand tools—I thought of software tools.

I remember when I first became “test-infected.” I had read a book by Robert C. Martin (“Uncle Bob”) called Clean Code and jumped straight into using JUnit at work. My coworkers thought I was crazy, but I persisted, and very soon I had a large suite of tests. No one else used them. There was no continuous integration server, so the only way I found out if code was broken was to run the tests myself.

After awhile I came to dread running my tests—because no one else ever ran them, they were broken most of the time. Fixing them was a nightmare because to be honest, my tests were a bit of a mess. I’m sure I understood them when I wrote them, but when I went back to them after weeks or months, it was hard to remember why I’d written them in the first place.

The final nail in the coffin for that test suite came in the shape of a seemingly innocuous change request. The new feature required an extra parameter on an interface, and as soon as it was added, all my tests broke—they wouldn’t compile. If the tests had been well-factored it would have been an easy fix, but they weren’t, and it wasn’t. They live on now in my nightmares alone (and possibly in a long, superseded revision in the version control system).

The next place I worked had a healthy developer testing culture. I learned that I had incompletely understood what developer tests are for and how they help the development team. I also learned that tests need to be as well-written as the code they test; that tests have to be easy to understand, otherwise no one will love them; and that they have to be run constantly and treated with respect, or they will rot and become a burden.

When I first used JUnit, I got sucked into the tool and all its cool features. I’d lost sight of the problem that needed to be solved, which was making it easier to develop new features and deliver value to our customers. I’d forgotten the first rule of software development: The code must be easy to understand. After all, it gets read far more often than it gets written.

Years later I came upon the work of Ward Cunningham, Dan North, Gojko Adzic, and others about behavior-driven development (BDD). I started playing with Fit, FitNesse, JBehave, and Cucumber and began to see how powerful these tools were when used to help bridge the communication gap between the technical and nontechnical members of a development project. In fact, I got so excited that I joined the Cucumber development team.

But Cucumber is just a tool, and it can be misused just like I misused JUnit. The powerful idea that drives BDD is that the nontechnical participants (customers, product owners, business analysts, etc.) have to communicate effectively with the technical team if the goal is to deliver amazing products. They must collaboratively discover exactly what problem they’re trying to solve, and in the process develop a ubiquitous language that everyone can understand unambiguously.

A side effect of this process is that tools like Cucumber can use the output of this collaboration as the basis of automated acceptance tests. This is very cool because now business people can read, understand, and even write some of the automated tests that prove the product does what the customer wants. It is so cool that lots of people forget that it’s only a side effect. When people begin to ask questions like, “How can I reduce the cost of my test effort?” these excited people answer them (wrongly) with “Cucumber!”

Over the years, I’ve seen many people come to Cucumber looking for a test automation tool. My experience is that these people often leave disappointed when the Cucumber community gently explains that Cucumber is a collaboration tool first and a test automation tool second. Aslak Hellesoy even wrote a post on the Cucumber Pro blog about this.

Liz Keogh, another leader in the BDD field, goes as far as to say that it is the conversation that is most important. The next most important thing is to record the conversation in some way. Only then should we concern ourselves with writing automated tests based on the conversation. Focus on the problem, not on the shiny new tool.

In The Cucumber Book and the new Java version, The Cucumber for Java Book, the other authors and I dig deep into why so many BDD and Cucumber projects fail to deliver the value they ought to. In fact, one of the most important chapters discusses many of the antipatterns we have seen over our years of consulting and coaching. In the original version of this book the chapter was titled “When Cucumbers Go Bad,” but we found that many readers skipped the chapter because their Cucumber scenarios weren’t bad . . . yet. In the new version, the chapter is called “Keeping Your Cucumbers Sweet” because it is much easier to avoid a problem from the start than it is to fix it later.

It is possible to find a new, innovative use for a tool, but it’s much more likely that you’ll do better using the tool in the way its creators intended. And whenever you reach for a tool, check that it’s actually going to help solve the challenge you’re facing.