- No one wanted to "collaborate", or check a "documentation" based on the Cucumber code. Yes, it's code, it lives in an IDE, in git, and non-technical folks just generally don't deal with that world. No one in my projects ever even brought such an idea up. Non-technical folks looked at our Cucumber code as in "what tests do we have?" or "how do you guys work". Nothing in their domain.
- Why do we have programming languages and don't programm computers using natural language? You'll find out when you try BDD! You end up coding the complexities that natural language glosses over, you'll fight similar Cucumber statements trying to get some reusability and so on. In the end you wonder why you bother with the 1-2 extra layers of Cucumber anyway.
- At the same time, good test code is easily readable for semi-technical people. In testing it ends up with a lot of clicking and entering values in text fields in an application the business analyst will be familiar with. Whenever they are willing, they'll figure out Selenium code.
- Have you ever wished that you have some
Scenario: Sunday isn't Friday
Given today is Sunday
When I ask whether it's Friday yet
Then I should be told "Nope"
I would advise against BDD/Cucumber and to be convinced otherwise I'd have to see a well though-out and realistic working example.
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
I think the language used language isn't the main blocker here.
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.
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.
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 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.
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)
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.
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...)
Fast forward to yesterday, we were formatting product specification using ChatGPT and I thought hmm, ChatGPT would be perfect to take something vaguely structured and return it as a Cucumber spec.
And here I am today, Cucumber pops up again in my HN feed. It feels like law of attraction, butn not quite :)
that said, writing acceptance style tests directly in a real programming language with an appropriate layer of test-support library abstractions in that language, customised to whatever component is under test, can often be quite pleasant and productive.
The business therefore always loses interest.
It's weird how business folks can just go "nope not doing that" to a process that was created to give them more say and doesn't make sense without them.
Is saving a tiny bit of money that much more important than a smooth handover? Or are employees just not willing to work their notice periods?
It sounds like in this case it's actively going to hurt the business.
It's a bummer but a labor of love that's acquired by someone else....is no longer your baby. If it's not generating revenue by the new company they're going to kill it. Heck, even if it is generating revenue they still might mess it up. That's really the sad part of acquisitions. Hopefully he took away some cash at some point.
Certainly laying someone off when they are on holiday feels like a dick move, I guess that's corporates for you. I'd be interested in Aslak's viewpoint, as I'm guessing he's still there, and may well be the source of Matt's confidence that community assets will be handed over to the community.
But I'm glad Matt is reasonably happy. I'm absolutely certain his next venture will be successful, and that SmartBear lost a very valuable asset here.
But the two can be similar in that if you are valuable you won't get fired or laid off, unless the company is in serious trouble.
Sometimes you are just on the wrong project. It is good to be generally aware of your projects value if you want to keep your job.
Cucumber, IMO, died like 8+ years ago and never really made sense. It was useful for a team to define requirements and then see the progress to implementing them, but Gherkin was a sticking point and integration tests are hard to get/keep working, esp with javascript apps that are now so popular. The fact that someone would pay a OSS maintainer up til now seems like a crazy waste of money.
Took me almost a year to stand on my feet again.
Life is Good!
I feel you. There've been some wild swings in the past 20 years.
Given that Gherkin language is insultingly stilted and simplistic, when I see Cucumber, then I want to vomit.
For LightBDD, developers write Given-When-Then tests in C#, and the test run spits out Gherkin style reports in various formats including a rather nice HTML page.
Chosing to use Specflow/LightBDD depends on how much you value the reports. At least with LightBDD, you are not forced to write the tests in the report format.