I will never understand the reason for Cucumber to exist. As you say, it just introduces unnecessary complexity for no reason.
If you can't code, you shouldn't be writing automated tests. Most of the "benefits" of Cucumber can be gained by using a good reporting framework. I like to use Serenity as I love its reports.
> I will never understand the reason for Cucumber to exist
In a previous company I had one use-case that I thought cucumber helped out a lot at.
We were writing software that would be vigourously tested and approved by a customer who didn't have any technical knowledge. Their initial plan was the "Excel sheet of death" test case management system with really fuzzily named tests.
I convinced them to write Cucumber tests, which turned out to be around 100, using the very explit syntax that then got called stupid by the cucumber devs and moved to the "training-wheels" gem. I never expressed what we were doing as cucumber tests. I just told them "Write them like this and it is easy to understand" and they agreed and did so, then they were signed off by our project team and them.
After that I then automated them our side so that we could run them quickly and easily in our pipeline while the customer could still use the tests for their tedious manual user acceptance testing at the end.
It worked out quite well. The customer never knew we automated the tests our side, they were just thrilled that something like 99% tests passed first-time and the 1% that didn't were down to interpretation differences.
Congratulations! I think this is actually the first time I've seen a use for Cucumber. Obviously, it would have been better if you didn't have to do this but I've spent enough time as a consultant to know when to just work around the customers.
The fact that gherkin can be be turned into an automated test is a side effect. The real purpose is to get non-programmers to put their requirements in a rigorous form so that programs can implement the spec and know it will do what is intended.
I have never seen it work in practice, but that what it is supposed to be about. If your managers are not looking at the gherkin and making suggestions then there is no point in doing it.
I'm a big fan of the Gherkin syntax and the output of my Example Mapping sessions is generally a big pile of them.
Automated tests are then written based on these but not "using" these. By not "using" the Gherkin scenarios for our tests we can be looser with the language and not have to worry about RegEx.
If a manager, or other non-coder, wants to see the tests, they can look at the very pretty report that was generated.
I can count on zero fingers the number of times I've worked with a non-technical QA person who's written tests, let alone benefitting from cucumber. As the GP says, the rest of the time is just wasted maintaining a pseudo-natural language programming language.
Unfortunately, I'd need a few more fingers. Not too many though which makes that argument for Cucumber fairly moot. I did work somewhere where each team had 2 testers. One to write the cucumber and one to write the glue code for it. It was about as successful as you could imagine.
I'd also say "non-coding" rather than "non-technical". Coding is just one aspect of being "technical".
There is benefit in making the tests easy to read but this is better done in actual code, e.g. the screenplay pattern.
My experience with trying to use Cucumber for tests pretty much shown me that it doesn't work there. But one thing that I played a bit and seemed that it might work was using Cucumber for writing requirements. At least for when the requirements are written by not technical people, it could give them better structure and for me as a tester make it easier to spot possible problems in them. But I haven't had to chance to try this more, so it might up end not working just like tests themselves...
yeah we had cucumber at a company I worked for. it was touted that PMs and other non-coding staff could write tests and how great that would be. After we switched tests to the Golang cucumber implementation, exactly no one outside of Dev team wrote any tests. meanwhile Devs have to use this awful new framework everytime we make a change. burn it with fire I say
"Not being able to code" is not black and white. Many can follow basic steps, as long as it gets not too complex. Thus "Low code" tools like Powerautomate,selenium ide, ahk or UIvision are great for people to do test automation. They are a quick way to create an automation. And many users learn/start to code this way.
If you can't code, you shouldn't be writing automated tests. Most of the "benefits" of Cucumber can be gained by using a good reporting framework. I like to use Serenity as I love its reports.