71–76 of 76 posts
> Cucumber lets you write automated tests in plain language No, it doesn't. Or to be more precise: Cucumber lets you write your tests twice - once in something that isn't nearly as close "plain language" as it seems at first glance, and then again in a horrible mismash of regex spaghetti code that will make you wish you'd been born a thousand years before computers were invented. I was forced to try to use it about 1…
I’ve seen (somewhat) experienced engineers get lost in complex pytest environments that used a lot of mock objects. Over time, they lost clarity on what was being tested, how, and why.
The real value is to have an automated set of simple smoke tests.
Frankly, Cucumber serves a nonnegotiable reminder to me that the automated tests should be simple and straightforward.
For anything extremely complex, I’ll write unit tests instead of trying to craft ridiculous gherkin steps only used for a specific scenario. None of this “when it is midnight of a blood moon in a leap year and the second request attempt has timed out…”
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…
The other one, and the one that is talked about more, is control of the methodology by the individual dev team, rather than as an external dictate from outside.
But the one relevant to Cucumber is that development isn't an activity that the dev team does alone, but a high-contact relationship between the dev team and the people working in the application domain that the software serves.
Like many Agile tools, it is completely broken when divorced from those organizational principles. Unfortunately, while lots of shops are "Agile", those "Agile" implementations are almost invariably completely divorced from those principles, and are the same kind of consultants-sold-this-canned-buzzword-bingo-approach-to-management-and-now-it-is-imposed-on-the-software-team-we-keep-walled-off-from-business thing that the entire Agile movement was a reaction against.
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…
Its one of many tools that is founded in one of the two key organizational realizations underlying Agile software development that, unfortunately, is completely ignored everywhere that pretends that they are "doing Agile". The other one, and the one that is talked about more, is control of the methodology by the individual dev team, rather than as an external dictate from outside. But the one relevant to Cucumber is…
There is a narrative, pushed by its creators, that cucumber isnt broken it is just misused.
It's a narrarive that needs to die.
It is equally bad as an agile collaboration tool as it is a testing tool.