[Guid_NewGuid]

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 for no real benefit.

[quietkoala]

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 abstraction layer to maintain.

[bluGill]

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.

[MoreQARespect]

I find it sad that cucumber managed to pour so much cold water on the idea of readable spectests. It's like if we gave up on programming because COBOL was bad.

[c-hendricks]

Ding ding ding. If it's not product / other people writing the specs, your job as a developer is now:

- write specs in a cucumber fashion

- write parsers to go from cucumber to whatever objects / data you expect

- finally write your tests

[MoreQARespect]

The problem isn't really that the domain experts or business people aren't interested in reviewing these tests. The problem is that the cucumber language is just very, very poorly suited for writing anything beyond very basic specifications.

In practice when people try to use it for anything semi-complex they inevitably end up either writing very vague tests or repetitive tests, neither of which are of much interest to stakeholders.

I've used docs generated from hitchstory for having conversations with stakeholders. I've also shared semi-human readable unit and e2e tests - especially when it's, say, JSON snippets in an API with technical stakeholders.

Unfortunately, except for a few domains where specs can be expressed very concisely, cucumber isn't suitable for that.

[QuercusMax]

I've been involved (mainly as an observer / code reviewer) in a process to go from test cases that are written out as a set of steps and expected results to a using "BDD-style" cucumber/gherkin test descriptions.

Going from "Step 1: Do X. Expected result: Y. Step 2: Do Z. Expected result: Q" to a big long "sentence" describing these steps joined with "and" (without the expected results being linked to each step) is strictly worse in just about every way. The actual automated tests are still being written the same way they always were, the descriptions of them are just WAY harder to understand.

[dragonwriter]

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 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.

[MoreQARespect]

>Like many Agile tools, it is completely broken when divorced from those organizational principles

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.

[dgunay]

Yeah this was unfortunately my experience too. A lot of head nodding and a token effort up front but they quickly reverted back to playing telephone on Jira tickets. A year or two later we're slowly ripping out the cucumber tests and replacing them with tests in our implementation language.

It's a two way street. I'd highly recommend never implementing it unless product is the one driving it, and actually makes it a priority.

[montroser]

Yeah, it basically just means that now you need both a business person /and/ a dev to hold their hand in order to write tests. Business people have business things to do and don't really want to spend their time writing tests anyway.