Chapter 6
When Cucumbers Go Bad

When your team first starts to use Cucumber, it won’t be long before you start to notice that you seem to be creating code with fewer bugs than you did before. You might find yourself bravely refactoring code that previously you would have been too scared to touch. You’ll continue adding feature after feature, inspired by the delight you felt on seeing your first passing scenario.

After a while, however, things can start to turn sour. Suddenly it dawns on you that the tests take a really long time to run. Or perhaps you’ve started to notice a couple of scenarios that seem to fail at random, usually just when you’re up against a tight deadline. Perhaps the nontechnical stakeholders have lost interest in the process, and only developers are reading the features anymore. People might even start to ask this:

Is Cucumber holding us back?

The good news is, there are solutions to these problems. In our coaching and consulting work, we’ve seen all kind of problems experienced by all kinds of teams as they learn to use Cucumber. In this chapter, we’ll describe the most common problems we’ve seen. We’ll help you understand their root causes, and we’ll make suggestions for tackling them or, ideally, avoiding them in the first place. There won’t be much code in this chapter, but you’ll find lots of useful advice.

We’ll start where it hurts, by describing four different symptoms your team might be experiencing. Then we’ll dig down into the underlying causes of these, before finally looking at solutions. By the end of the chapter, you should feel much more confident about how to help your team stay successful with Cucumber in the long run.