It sounds great on the label, but what you’ll end up with are single-use matchers for almost every line of your cukes, annoyance maintaining the regexes that map your cukes to the actual test implementation, and the “non-technical” people won’t be maintaining the cukes anyway. Sure, let them specify the cukes if they want, but then translate them into regular unit tests or specs and forget maintaining them.
Just like all the other no-code inventions out there, they fail to reckon with the fact that essential complexity isn’t a problem with programming language syntax.
I have had a similar experience. It just end up being a abstraction layer that gets harder and harder to map to underlying code as a project grows.
If readable tests are the goal, I think the time is much better spent cleaning up regular tests and writing well-named helper methods. Especially in Ruby you can get pretty close to tests that can be deciphered on a high level by non-programmers. That said, I've never had a PM or other non-programmer actually want to do that.
I have ended up writing BDD scenarios as plain code comments with conventions like capital “GIVEN” etc. A simple script to scrape test files and generate a markdown file to browse.
Then you refactor your common helper functions as natural, but you’re not forced to enclose them in steps.
> but what you’ll end up with are single-use matchers for almost every line of your cukes
Capybara has this problem as well as do other web acceptance tests. Maybe not every time a new matcher but frequent enough. Mostly because of the high variability of HTML paths. You have to design your HTML in a way (use lots of [title] tags and standard HTML) if you want to avoid it.
That's pretty much the essence of it. It's a cargo cult for scrummasters shifting a huge burden onto test maintainers for negligible benefit.