Hacker News Reader

I've never seen Cucumber used in a big project after having done contract work for a long time but the idea of having user stories defined in a systematic way that's only used as extra context / documentation for complex features is useful. That would be aimed at developers and it would live near the real test code so it's not necessarily a direct implementation of how Cucumber is intended.

For more basic things it's overkill, certain languages almost give you the same benefit with code itself.

For example, here's a real user sign in controller test from Rails:

    test "doesn't send email for an unknown user" do
      post sign_in_path, params: { email: "idontexist@example.com" }

      assert_enqueued_emails 0

      assert flash[:alert]
      assert_response :unprocessable_entity
    end

You don't need to know Ruby or Rails to have a good idea of what's happening there.

Non-technical folks write complete IT systems in the nightmarish programming language of Excel macros.

I think the language used language isn't the main blocker here.

yeah and than they argue that they can't program. or that they can't write down pseudocode of their excel macros.

but they use way more complex if/elseif/else statements than everybody. they know how to use the ridiculousness of a vlookup.

and than some of these guys figured out to use powerfx via power apps another behemoth of a excel kind of syntax and they still don't think tey can program.

language is definitly not the blocker. heck there are even people who write brainfuck, just to have fun.

I mean yeah cucumber is probably not the future of programming.

If I’m told to build a report or form collection for a product.

I always tell them to go build it in excel first. Than it to hand me. Sometimes I build it out in excel. 100% everytime they change everything about it several times over, but I can make all the changes requested in minutes instead of hours, days or weeks.

Implementing a working excel document in a modern language is trivial.

I think BDD has very bad reputation because people associate it with test automation. And it is actually pretty terrible tool to teschnicall describe tests.

What BDD is good at, is defining project requirments, it is a thinking tool. Especially if used correctly, with examples and etc. It is a business not engineering tool.

> I think BDD has very bad reputation because people associate it with test automation.

I think BDD has a terrible reputation because people associate it with Cucumber/Gherkin! And honestly, if that's all they've experienced, I understand and sympathize.

On the other hand, people seem happy with RSpec, Jest, Spek, Scalatest, and other spec-style BDD frameworks. Those still nudge people into thinking about testing use instead of implementation, which is the real value in BDD.

We tried it once and the semi-tech SMEs had no desire to write cucumber code so it ended up being the developers who hated writing in a second language. No real benefit.

The ideas behind BDD are sound, but I've never seen it work out in the real world.

In reality we as programmers need to turn what the stakeholders want into code. They will talk in meetings: we better take notes. They will write things down [in English or whatever language they speak], but it won't be code. There will be conflicting requirements, and we as programmers need to understand the topic well enough to make reasonable decisions on the easy stuff, while going back on the harder stuff - easy and hard is as the decision makes see things not as a programmer sees them: better know that too.

Once you figure out what stakeholders want turn it into code. It is useful to have integration tests for scenarios that they care about (some of them are stupid - the last version of an embedded product I worked in had a 5 length array, and it turns out some customers needed 7, and later analysis proved that 7 was the mathematical max anyone would ever want. The current version is C++ using a vector so the potential length is unlimited (limited by free memory), but we still have a test proving 7 works because the mistake in the past burned enough people)

I've done it plenty, just never in the context of cucumber (I find it gets in the way).

E.g. When a front end team says "we need an API to do X" to backend I dash off a couple of draft example API calls and responses and organize a 10 minute meeting where I show the draft to the front end team and back end team (stakeholders).

That discussion we have in the meeting where we 1) talk about what needs to go in the request and response while looking at it and 2) edit the example scenario and 3) finally lock down a version everybody agrees upon is, essentially, BDD in its purest form.

I'm pretty sure a lot of people do this type of thing without even realizing that it's BDD.

(A lot of people also dont do it and the mismatch in expectations only gets realized and negotiated around once there is code ready to deploy. This is an awful waste of time and effort.)

> some of them are stupid

This doesn't sound like a stupid test at all: it safeguards against a regression by preventing anyone from changing the vector code. In an ideal world every bug would be caught by a human once and only once, and thereafter be tested.

I don't mind developers writing the Gherkhin as long as the SMEs can read and sign off on the Gherkhin. They won't read a unit test for sure.

We have Cucumber tests and Rspec tests in our repository.

They are not mutually exclusive but complementary. Cucumber tests are integration tests and usually test only the happy path. In our case, a customer never sees those tests. OTOH for new developers, it's a very good way to find out how a given feature should work.

Making a test in Cucumber for checkIfFriday() would be flagged in a code review. That's for a unit test, not an integration test.

Complex test setups are way easier in Cucumber than in Rspec. They are usually more realistic than the Rspec ones. In the unit you can more easily cheat your way out of a correct setup.

One of the bigger problems I have with it is that discovering existing cucumber steps is hard. They are free form so anything goes and if you aren't careful, you will have a plethora of steps that are similar but different and someone without a lot of experience will not be able to tell which step is more suitable for a given scenario.

> One of the bigger problems I have with it is that discovering existing cucumber steps is hard.

When I was using Cucumber, we almost picked up Turnip to solve that one.

For anyone that doesn't know Cucumber, you have one global context for all expressive sentences. So if you say "I click on the big red button" then there has to be one reliable way to detect the big red button on whatever page you're on, and it has to be the same way in every context.

In Turnip, you can declare contexts (like namespaces or modules) that allow you to have the same expression mean different things in each context. Only problem is, Turnip is even more obscure than Cucumber, and even fewer people know what it is, let alone having used Cucumber well enough to understand what all that means and what Turnip is for.

The other problem being, having a single global context for understanding the meaning of words arranged into sentences was a very powerful tool for promoting reuse and expressive clarity: if you found yourself using the same utterance in two different contexts, it was expected that you'd clarify so they could be distinguished and understood separately in a context-free grammar.

Not needed anymore in Turnip, unless you're diligent about reaching for the existing modules that you've created. (On the other hand, having your test utterances sorted into modules makes it a lot easier to reach for them, among related utterances...)

To clarify, checkIfFriday() is supposed to be a random trivial non test-related piece of code. My rhetorical question was, "would you like to maintain a world of extra Cucumber on top of it?".

This is why we need better tools which will give benefits for the added complexity. If you need to create both the feature files AND the code, it's just complexity with little benefits. But frameworks like https://github.com/karatelabs/karate or https://github.com/Endava/cats are hiding this complexity and remove the code layer entirely. Which, in my view, this is where you need to be in 2023, particularly for API testing.

I'd completely disagree. Not necessarily for cats, which I wasn't previously aware of, but in my experience there's no benefit to having karate in the mix.

Why would you say that? Majority of code is repetitive. Why still focus on writing it for every project? I agree that you cannot have 100% of tests without actual code, but a significant percentage can just be feature files only.

Where I come from we do such revolutionary things as writing libraries and defining abstractions to avoid repetitive code. Why introducing a new tool with its own language for this seems like a good idea to anyone utterly baffles me.

Also, I should add, where I've seen karate used on teams it's deepened the division between devs and testers. So in addition to being questionable engineering, it's sociologically toxic.

Maybe a ChatGPT prompt could translate?