Why I Write Cucumber Steps with Step Definitions that Have No Code
And No, There’s Nothing Wrong with It
Cucumber is a software tool that can be used to facilitate Behavior-Driven Development and Specification by Example. Cucumber scenarios, which are short functional requirements specifications, can be written by anyone on your team—and then automated by developers and testers to become acceptance tests.
When I was learning how to use Cucumber and Gherkin, I was told writing steps with step definitions that don’t execute any testing code is a bad practice.
Here’s a quick example of a scenario for a text editor app that could be run by Cucumber. It talks about a feature called Focus Mode, popularized by apps like iA Writer. Focus Mode highlights only the paragraph you’re working on right now, limiting any other distractions.
Scenario: Using the Focus Mode Given Ernest’s desire not to be distracted
When he turns on the Focus Mode
Then the text editor should go full screen
And only the paragraph he’s working on should be fully visible
But the other paragraphs should be dimmed out
How on Earth could we write testing code to check whether a user feels distracted?
At first glance, the steps feels redundant. Including it seems like adding unnecessary work for whoever will implement the acceptance tests. A developer would certainly tell you that doing so increases the complexity of the test suite for no reason at all.
I don’t agree with this. Let me tell you why.
I think my answer becomes clearer when you realize that scenario emerge before you start thinking about tests and testing code.
When you think of your scenarios as just a result of a testing phase, then yes—steps with empty step definitions are useless.
But when you embrace the mindset of organizing your development process around collecting examples and refining scenarios — then you can see a fluid progression between development phases.
Imagine that you’re sitting in a collaborative workshop, trying to analyze the Focus Mode feature. It would actually be extremely natural to write in a scenario that Ernest doesn’t want to be distracted, since that’s why you invented the feature in the first place. You could even make the Focus Mode a big element of your marketing value proposition for the app—exactly like iA Writer did back in the day.
Keep in mind: such workshops—like, for instance, the Three Amigos workshops—take place before you write any code.
Processes centered around scenarios, like Specification by Example or Behavior-Driven Development, redefine the distinction between analysis, design and implementation by building a bridge between requirements and code. You should see writing scenarios as a process of continuous discovery through reducing their uncertainty about the requirements, not a singular activity or a phase to go through, and certainly not a hurdle stoping you from coding. When you look at scenarios like that, I’d dare to say a step like Ernest’s desire not to be distracted becomes pretty damn valuable. It increases your empathy.
This is why I think that instead of not writing steps with empty step definitions, you should make a habit of not writing steps that don’t bring any value to the users or the delivery team. These are two different things.
Change the paradigm and use scenarios as a tool for analysis, design, implementation, and testing. If you do that, you’ll see why writing steps with empty step definitions isn’t such a bad practice after all.
If you want to read more about Cucumber, Gherkin, BDD, and Specification by Example, I’m writing a book just for you. “Specification by Example using Gherkin” explores the art of writing great scenarios and will help you make executable specifications a core part of your development process.
My name is Kamil Nicieja. I’m the co-founder of Ada, a platform where you can rent your next apartment, tested with Cucumber. Over my career, I built software products for companies from the US, the UK, Australia, Canada, Germany, and Kenya.
