I read this article by the creator of Cucumber the other day, and then heard some follow-up questions elsewhere, about why so many people misuse this tool.
It’s not the first time articles like this have come up. When a tool is made to solve something, it can be irritating when people use it to solve different ones.
I think though, that the way people use Cucumber shows that the users have certain needs that wouldn’t be solved by using Cucumber as originally intended.
Today I’d like to show how this misuse really is advantageous.
Addressing the Needs of Users
What Cucumber sets out to do is:
- create executable specifications,
- foster collaboration, and
- provide test automation.
And it does this at the beginning, when a feature is specified. People get together (collaborate), talk about what the feature’s supposed to do, write it in Gherkin format (create executable specifications), and back it with code that exercises the feature (provides test automation).
What I’ve noticed though is that every place I’ve seen that uses Cucumber, uses it after the development’s been done.
Although every company I know of that uses Cucumber refers to it as BDD, literally none of them use it as such. They use it to perform Behavior Driven Testing.
I don’t think this is a training issue. Enough people can read about what Cucumber’s for, and decide whether (and how) to use it.
And yet, so many people use it as a BDT tool instead of BDD. Why?
Is There an Advantage to It?
I say yes. As a professional misuser of this tool, I’ve noticed different yet similar needs in the market:
- We need to know what’s being tested
- Our automation’s hard to build and maintain
But the cool thing is, Cucumber addresses these already.
What’s Being Tested?
When automation’s working layer is written in code, the number of people who can read and understand it is smaller. It’s likely only developer-level people can get a handle on what the automation’s actually doing.
But when it’s written in Gherkin format–plain English–even though there’s code backing those step definitions, you don’t have to see it to understand what the tests are doing.
This is very helpful for getting non-developers to understand what’s being tested–and if written in a granular enough format, can allow non-developers to contribute to the automation effort too.
If that’s not collaboration, I don’t know what is.
Creation and Maintenance
When automation’s hard to create, less of it gets made, which can increase exposure to bugs. When automation’s hard to maintain, it can become a bottleneck, which has the same result.
With Cucumber, the mental translation that comes from taking an idea and translating it into program code is minimized. Once the step definitions are fleshed out, less time is spent on, “How do I write the code to do [this]?” and is instead put on building out tests with known chunks of functionality.
And yes you can do that during development, but how much will you have to change the tests to have them still work? Testing code that’s not complete is hitting a moving target. What I’ve found is that a lot more maintenance is done on automation at that point, than after development’s complete, which further demonstrates the trend of Cucumber being used after the dev phase.
Thinking Outside the Box
Cucumber’s a great tool. But I think that either the target’s moved, or was wrong to begin with. And in a day where missing defects can spell disaster for a company, it’s worth trying to bend some rules.
After all: It it’s stupid but it works, it ain’t stupid.
I hope this challenges you to think that using a tool outside its designed intent isn’t a wrong or bad thing. Although Cucumber was created to be used before development was complete, it’s being heavily used after development’s done. Right now, that’s what needed.