One of the biggest problems in my opinion when we automate with Cucumber is having to perform constant maintenance. So I’d like to know if you still adopt Cucumber on a day-to-day basis.
I really like the gherkin syntax and scenario outlines. I tend to advocate for those in Jira tickets and then I copy that into the test implementation as a comment or doc string.
You can still relate the step to sections of a test in whatever framework you are using.
Avoids the maintenance overhead and decouples the test definition from a specific test framework.
I’m a big advocate for cucumber. As with everything it does add another layer to maintain but when used in conjunction with acceptance criteria using gherkin it works really well.
Hey Crystiane. I’ve definitely seen the maintenance issues you’re talking about, and in my experience they usually come from where the detail ends up living. Cucumber starts to feel painful when the feature files drift into describing interactions rather than behaviour.
If scenarios contain things like clicking buttons, typing into fields, following specific UI flows, or referencing particular labels, they become tightly coupled to the UI. Any small UI change, even something cosmetic, ends up breaking multiple scenarios, which is frustrating for everyone.
What has helped in the teams I have worked with is keeping the layers clearly separated:
- Feature files describe behaviour or rules, not step by step UI sequences. One scenario per behaviour, written at the level of intent.
- Step definitions should not know about drivers or selectors. They should delegate to helpers or page objects that handle all the actual interactions.
- The automation layer is the only place that knows about the UI. When something moves or changes, you update it in one place rather than across every scenario.
- Avoid hard coded data or fragile details in Gherkin. Things like credentials or element names belong in the automation layer too.
With that separation, maintenance tends to drop significantly, because the scenarios remain stable even as the UI evolves. The feature files act more like living documentation rather than scripts, and the brittle parts are isolated where they are easier to manage.
I think Cucumber still works fine day to day if it is used at the right level of abstraction. If the scenarios become procedural, or the step layer knows too much about the UI, it can become difficult to keep under control.
Where I still find Cucumber genuinely useful is when a team is using it to build a shared understanding, a common language between product, dev, test, and anyone else involved. If the scenarios are treated as examples of behaviour and a prompt for conversation, it tends to work well and the maintenance cost is much lower.
Where it tends to fall apart is when Cucumber is used primarily as an automation framework in its own right. Things like big reusable step libraries, or trying to drive a whole UI test suite through Gherkin, usually make the tests harder to maintain and harder to reason about. At that point you are fighting the tool rather than getting value from it.
If people really like the readability of Gherkin, it is worth remembering that you do not actually need Cucumber to benefit from that style. You can write Gherkin like examples directly in Jira, in docs, or even as comments in your tests, and still use a more lightweight automation framework underneath. The value comes from the clarity of the examples, not from binding every step to an executable definition.
So for me, Cucumber is worth it when it supports collaboration and helps the team talk about behaviour. When it is used as the backbone of UI automation, the maintenance overhead often outweighs the benefits.
1 Like
My first question is whether this is about Cucumber as a tool or your approach to writing tests, which uses Cucumber.
I think @vivrichards captures the methodology where using a tool like Cucumber can work really well. It needs you to understand what you’re testing (behaviour) and how to use the tool effectively.
I’ve not used Cucumber itself but I’ve used SpecFlow in an environment where it was used very badly. The team had decided to “do BDD tests” and misinterpreted that as write complicated & hard to maintain tests that arbitrarily use Given-When-Then.
Earlier this year I piloted an initiative where we skipped the cucumber/ SpecFlow tooling but stuck to the concept of how to write these tests. Our test cases would have the gherkin in the test summary comment (similar to @MarkJB) and then we had clear steps within those test cases. These steps would then call the automation layer that did whatever magic was required. In Jira I could then link to the high level tests in GitHub.
Was SpecFlow/cucumber required? No. We achieved our goal of mapping acceptance criteria to automated checks. This has its own maintenance of course, which importantly was never enforced. If the project was longer term I absolutely would have made that next step.
Just want to highlight a key point by Viv.
I would definitely advocate for using Cucumber but would challenge why you’re using it day-to-day. Target using cucumber for acceptance tests to verify the behaviours in acceptance criteria but remember:
- Tests are not limited to defined behaviours.
- Different tests are suited to different types of automation.
- You don’t need to automate every test - many aren’t suited to it.