Live data from Hacker News

Cucumber lets you write automated tests in plain language

cucumber.io

31–40 of 76 posts

Re: Cucumber lets you write automated tests in plain language

#31
I posted this comment in 2013 [1] and I stand by it 12 years later:

Cucumber tries to solve the problem of turning customer requirements into 'real code'. In exchange for that worthwhile benefit, it asks you to implement the most terrible, reg-ex based spaghetti code imaginable.

The problem is that it doesn't solve the original problem AT ALL. And then you are left with terrible reg-ex driven spaghetti code. Like the Jamie Zawinski saying, "now you have two problems".

The lesson here is that software development processes have to pass the 'human nature' test.

The software industry has largely abandoned waterfall development because it just doesn't work well in practice. It doesn't work because people don't know perfectly what they want before they build it. Agile processes usually are much more efficient because they are more closely aligned to how humans solve problems in the real world.

Cucumber suffers from the same issue of being disconnected with reality. In theory, you can find a customer who can give you perfectly written use cases and you can cut-and-paste those into your cukes. In practice, that never, ever works. So let's all stop wasting our time pretending it was a good idea now that it has been shown to not work.

[1] https://news.ycombinator.com/item?id=6411787#6412391

Re: Cucumber lets you write automated tests in plain language

#32

In my misspent youth I've tried to introduce Cucumber/Gherkin a couple of different times but it's something with a deceptive promise. The preconditions are that you have domain experts or business people interested and willing to engage in writing or reviewing these tests. Unless you have this and it's something that those people are going to sustain when the going gets tough you're just making writing tests harder…

What is it about Cucumber that is so attractive to early in career engineers (myself included)? Is it the naive belief that others, non-engineers even, will actually want to read or write your tests? It's great in theory, but like many ideologies that attract young people, political or otherwise, its promise of egalitarian test authorship rarely holds up in practice. My experience is that it ends up as an extra abstr…

I spent a lot of time tryngito figure them out mid carreer before I realized that high priced consultants made a lot of money selling training me on it to management. The same salesmanship worked on me. Perhaps in part because they were also teaching unit testing which did turn out useful - once I got rid of the bad ideas they taught since they didn't know what worked in the real world but had a lot of money to make by sounding confident when asked questions.

Re: Cucumber lets you write automated tests in plain language

#34
As a software developer, I have enjoyed occasionally writing Cucumber/Gherkin. However, the roles that were _supposed_ to be writing it did _not_ enjoy it, either refusing to write it or writing unusably-brief and -malformed versions even after extensive training.

Re: Cucumber lets you write automated tests in plain language

#35

Engineers should refuse to write Gherkin. It's not meant to be for them, it's meant to be for non-engineers to tell engineers (or the systems the engineers make) what they expect will happen. It looks like some flavour of user stories for this reason. Engineers' responsibility begins at the "code behind" the gherkin layer. Someone needs to enforce this. Sadly, IMO because gherkin looks like structured language (i.e "…

This managerial anti-pattern crops up with so many DIY tools; like reporting/dashboard platforms where engineers go through all the work funneling data to a 3rd party tool just for management to open tickets asking the same engineers to build dashboards in the UI. If we knew we were going to get stuck making the reports too, we'd probably choose any option that let's you specify them in some kind of code/markup instead and commit it to version tracking rather than a proprietary platform and their own internal history etc. etc.

Re: Cucumber lets you write automated tests in plain language

#36
This sparks a thought experiment I've been having. In this world where llms can be thought of as the new layer of compilers, things like pickle are likely going to be the main unit of work for humans.

Only now instead of this developing brittle generated tests, it will instead be used by the llm as guidance to generate the actual code and tests.

Before people jump down my throat, I know we are nowhere near that today and I promise I'm not pitching this to my leadership because they would gobble it up too fast.

But for us engineers, I think there is an interesting space for thinking of llms as akin to garbage collection, a feature that allows us to abstract to a slightly higher level of thought. Yes we still need to know how to check under the hood, but this is looking like the right level of precision-flexibility ratio that llms thrive in

Re: Cucumber lets you write automated tests in plain language

#37

I posted this comment in 2013 [1] and I stand by it 12 years later: Cucumber tries to solve the problem of turning customer requirements into 'real code'. In exchange for that worthwhile benefit, it asks you to implement the most terrible, reg-ex based spaghetti code imaginable. The problem is that it doesn't solve the original problem AT ALL. And then you are left with terrible reg-ex driven spaghetti code. Like the…

Nobody is going to read these test cases any way, except when troubleshooting or adding new code. But that is never any of the stakeholders

It's quite funny that now with AI-based no/low code the same thing is attempted again. Even if the regexes might disappear, it's even more text, with even less structure (assuming anyone checked those prompts into git in the first place)

Re: Cucumber lets you write automated tests in plain language

#38

This sparks a thought experiment I've been having. In this world where llms can be thought of as the new layer of compilers, things like pickle are likely going to be the main unit of work for humans. Only now instead of this developing brittle generated tests, it will instead be used by the llm as guidance to generate the actual code and tests. Before people jump down my throat, I know we are nowhere near that today…

I'm building this over at https://zapcircle.com/ - it's still a work in progress, but it's all open source.

The idea behind it was that Behavior-Driven Development might be a great idea, but Gherkin was a pain to work with. LLMs bridge that gap now:

https://www.jefflinwood.com/2025/zapcircle-bdd-2025/

Re: Cucumber lets you write automated tests in plain language

#39

I posted this comment in 2013 [1] and I stand by it 12 years later: Cucumber tries to solve the problem of turning customer requirements into 'real code'. In exchange for that worthwhile benefit, it asks you to implement the most terrible, reg-ex based spaghetti code imaginable. The problem is that it doesn't solve the original problem AT ALL. And then you are left with terrible reg-ex driven spaghetti code. Like the…

Nobody is going to read these test cases any way, except when troubleshooting or adding new code. But that is never any of the stakeholders It's quite funny that now with AI-based no/low code the same thing is attempted again. Even if the regexes might disappear, it's even more text, with even less structure (assuming anyone checked those prompts into git in the first place)

I use executable specs quite a lot with stakeholders.

I'd never ask them to write them, but I will often write a spec/test based upon their two sentence jira and then screenshare and walk them through my interpretation to get feedback early (i.e. before ive wasted time building the wrong thing).

Cucumber/gherkin is awful at this of course, and the regex thing was a terrible idea but it's not the only tool.

The idea that tests should be split into a specification layer and execution layer is a good one that should have taken off by now.

Re: Cucumber lets you write automated tests in plain language

#40

I posted this comment in 2013 [1] and I stand by it 12 years later: Cucumber tries to solve the problem of turning customer requirements into 'real code'. In exchange for that worthwhile benefit, it asks you to implement the most terrible, reg-ex based spaghetti code imaginable. The problem is that it doesn't solve the original problem AT ALL. And then you are left with terrible reg-ex driven spaghetti code. Like the…

Nobody is going to read these test cases any way, except when troubleshooting or adding new code. But that is never any of the stakeholders It's quite funny that now with AI-based no/low code the same thing is attempted again. Even if the regexes might disappear, it's even more text, with even less structure (assuming anyone checked those prompts into git in the first place)

But, as a software engineer, writing tests is probably the primary place AI gives me value. I can simply write tests much faster than writing them manually, and as a consequence, I'm a lot more likely to write tests that cover more cases. I still review all the code output, but the consequence of me missing a bug is much less than missing a bug in production code.
Post reply on HN