Cucumber maintainer has been laid off(mattwynne.net) |
Cucumber maintainer has been laid off(mattwynne.net) |
- 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.
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.
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.
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.)
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.
There is fired for cause cases where the login stops working at the same time as your pay stop, but for cause means you screwed up, and your pay probably should have stopped several months ago but it took time to investigate to ensure you really were that bad.
Granted small companies will often say "sorry we are out of money, don't come back Monday".
It’s frustrating hiring Europeans for this reason but at least they are significantly cheaper to pay than in the USA.
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.
It is terrible for simplifying things. Most people really know "I want ta safe self driving car", they don't want to figure out when it is acceptable to hit a kid on the road (think gory video games were people throw babies in front of your car for one case where it would be acceptable).
The restricted nature of the language encouraged this "dumbing down" of the high level requirements to the point where you couldn't really have intelligible conversations about gherkin scenarios without referring to step definitions, so the whole exercise becomes kinda pointless.
If your software scenarios had even slightly complex preconditions/steps then most people would just shove that complexity in a definition and paper over it.
The idea is to get to what is different about this user. Security is important enough that you always want to specify a logged in user, but most details you don't care about and shouldn't ambiguous is good because it says I don't care.
I have worked at a company that had the policy that any time an employee gave notice that they were leaving, the employee immediately had their access credentials revoked and was walked out of the building by security. The justification for this policy was that the employee might decide to sabotage systems if they were leaving.
While I think it is unnecessary in nearly all cases, I can at least understand the reasoning for a policy of immediately cutting access and walking an employee out after that employee has been informed that they are being fired or laid off. But there is NO sense in having the policy for employees who are choosing to leave. The policy of walking employees out immediately was well known. If such an employee HAD wanted to sabotage systems or plant a back-door, they would have done so after deciding to leave but before informing their managers. The policy served no rational purpose.
Imagine being a Google cloud customer and hearing that they need to give employees no notice of a firing in order to protect your data. Like that implies employees have unrestricted access!
If the answer to both of them is nothing then you've got a problem.
---
Well, first your question has a frame-challenge problem. Most SWEs are like a factory creating tools that an end user can then use/consume. You don't want to be in a situation where if there's a power outage in the factory then all of your smart lights stop working. The amount of people that would need sudo to customer-related machines is extremely low and so trivially they wouldn't need to be fired with no notice.
Sticking with the frame-challenge problem. There are many non-sudo activities that an employee can do. Literally their sudo access could be revoked no-notice and then they're given time to do knowledge transfers / pass off their on-call rotations / etc. For most of these layoffs the individuals are still employees for the next 60 days (WARN Act has a 60d notice period, this is why all the severances are worded so weirdly in that the employees get 60d of pay and then a lump sum of X. The lump sum is severance, the 60d is salary by-law -- they can't be fired yet).
The `sudo` command itself posses a problem for separation of duties but an invocation of it could be blocked without a review from multiple other people (perhaps that list is filtered by not-to-be-fired employees). It could also be that the command is set by one person (i.e. copy data) and the parameters are set by another person (i.e. machine1, machine2) and this can be done ahead of time (i.e. a template workflow).
So my not wanting to leave my home is not exactly agoraphobia.