Cucumber maintainer has been laid off(mattwynne.net)
mattwynne.net
Cucumber maintainer has been laid off
https://mattwynne.net/new-beginning
80 comments
There is also paranoia. A lot of people believe that a laid off employee will immediately go against the company and do some kind of sabotage or leak secrets.
Remember that you're balancing the odds of it happening against the possible harm it can cause. If it's super unlikely to happen but the effects can be catastrophic, then it may be worth the cost to prevent it from happening.
This seems to be the same paranoia as the fear that some stranger will snatch a child as soon as parents don’t watch it for second. It may have happened but real risks are probably somewhere else.
Does that mean they think they would themselves do that? And on other hand do they not trust their own systems to protect from these actions? Or being legally capable of suing employees?
It's not exactly paranoia given there have been many examples of the fear becoming true.
Sometimes it is purely paranoia.
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.
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.
I mean employees also leak/sabotage stuff while they're employed perhaps you should have a better system where 1 "rogue" employee can't trash it.
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!
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!
How would a https://en.wikipedia.org/wiki/Separation_of_duties system work where no one guy has sudo? Approve commands to run by digitally signing them? Missile silo keys?
Well, first take a step back and ask yourself what process do you have that prevents an employed rogue employee from doing something malicious? And then ask the obvious followup, what powers does a soon to be fired employee gain that lets them bypass those processes?
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).
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).
In this case it was one of the founders of the company. If you can't trust the founders, who can you trust?
Sometimes bad things happen to people when they travel outside.
So my not wanting to leave my home is not exactly agoraphobia.
So my not wanting to leave my home is not exactly agoraphobia.
Has it not happened in Europe for some reason?
People in Europe usually don’t have their healthcare and safety net tied to their work.
Usually if it’s a layoff (without cause) and the employee does not have special powers (officer of company) a long notice is given to support a transition. A compensation package which requires signing a contract is the incentive for the employee to cooperate.
In this particular case it looks like he was the co-founder of a business acquired by another company. Usually co-founders hang out for a time, but also usually not forever. How would you feel if you bought a house and the previous owners kept showing up to see the new decor? It's generally a short-lived relationship.
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.
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.
This happens outside of America. I believe it’s to avoid the risk of the employee maliciously causing damage after being given the news.
Yes, but in the US, pay usually stops immediately when the login stops working. In much of the developed world there's a guaranteed notice period and severance, and often limitations on what situations you can fire for.
Laid off in the US generally implies there is some severance pay. We do not get any details, but I would assume he gets some severance pay that he isn't talking about (he probably cannot, and it is possible given the details that he doesn't even know yet)
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".
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".
Generally pay is tremendously higher in the USA. Tech companies, although not compelled to, grant severances if you aren’t “fired for cause”. Also in most other places you have to give like a 3 month notice if you want to quit.
It’s frustrating hiring Europeans for this reason but at least they are significantly cheaper to pay than in the USA.
It’s frustrating hiring Europeans for this reason but at least they are significantly cheaper to pay than in the USA.
Companies just want a clean break. In cases where they really need you to do a hand off, you will get a transition period. I've had that happen to me, and it's a weird feeling. I don't think its great for productivity or morale, and is more common when you are shutting an entire division down.
I'm not suggesting that it is, but this sounds much more like a firing than a layoff. Pretty shitty way to do a layoff. This is the way you remove a potential problem, i.e., play it cool until the doors are locked, then full lock-out. That's very different from "Hey man sorry, but it's layoff season, as you know, so we're gonna pay you out for the next 4 weeks and you can keep your coursera subscription."
The difference is sort of meaningless. What matters is if you are getting severance or unemployment, and if you can get a recommendation. If they are going to fire you for invidual performance, youd think they would put you on a pip, but some companies will just wait and lay you off.
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.
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.
Been there. I was laid off, the same (shitty) way, returning from vacation on March 29 2009.
Took me almost a year to stand on my feet again.
Life is Good!
Took me almost a year to stand on my feet again.
Life is Good!
2009, one of the great vintages.
I feel you. There've been some wild swings in the past 20 years.
I feel you. There've been some wild swings in the past 20 years.
I know another person laid off from this same company last Friday. Pretty sure it was a layoff that impacted him.
As a tester, I have felt from the first time I ever saw Cucumber that it is part of a conspiracy by coders to avoid productive testing by trying to transform testing into code— like that guy who wrote scripts to handle all communication with his girlfriend.
Given that Gherkin language is insultingly stilted and simplistic, when I see Cucumber, then I want to vomit.
Given that Gherkin language is insultingly stilted and simplistic, when I see Cucumber, then I want to vomit.
That's really disheartening. Without access to his email, can Matt still be the primary maintainer of Cucumber? He can of course fork it.
Cucumber is very useful in projects with similar components and flows. Developing certain command patterns and writing tests on these commands really improves and speeds up the processes.
Being off the grid for more than 2 days puts you at a disadvantage if you value your Job, let alone taking long esoteric vacations. there are people working non stop to take all you have. If you value anything enough, protect it at all cost.
why did you post this twice with different wording?
Don't take more than two weeks at a time vacation let alone loose access to your email if you value your job. Ever. While we get there all esoteric on taking time off to rewind because we have added so much value already and the world is beautiful a worth exploring, there are many people working non stop to take what you have... bummer
This is terrible advice. One of the most important things in security (amongst other practices) is to ensure that people take regular longer breaks, because it's a great way of seeing where there are dodgy practices going on, and in particular people making themselves SPOFs. If you have inherent value, rather than just a castle defended by a moat of failing to cross-skill your colleagues, then you'll be safe taking longer holidays.
13 years ago when I started with Rails, we had a cucumber suite for one of the products we maintained. It was eventually abandoned, as developers didn't want to maintain it and the PM was not interesting in applying it either. I had never seen it on a project since, but still knew one or two people who were religious about it.
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 :)
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 :)
Isn't that often the fate of Cucumber(-like) projects: you start with the promise of high abstractions that the whole company can work with or reason about, you invest a bunch of time to bridge the gap to the underlying implementation, then it turns out that those business folks aren't really interested in it, so developers hold the bag, and bridging the abstraction gap becomes a cost with little benefit?
The same thing happens with BI platforms. Everyone asks for a tool that business folks can use, developers go through all the effort in creating data integrations, then they turn around and ask the developers to just make the reports they wanted anyways. If that's how it was going to be, there's a lot of simpler solutions than a full blown BI platform...
I have seen this repeated a lot here on HN. Since my industry is at least 10 years behind everyone else we are now getting these directives. Execs/managers say we want to put the tools directly in the hands of the users. The project is going to be failure in that sense though because nothing is oriented to do that. Everything from our change control process to the UI is a blocker. The execs keep shouting "it needs to be simpler!" on a process that's decidedly not simple. I'm not interested in leading a paradigm shift destined to fail from my small underfunded department at a megacorp so I switched projects :/
i think this has been the outcome every time i have seen BDD applied. when the only people maintaining the BDD suite are the developers, the situation can be improved by throwing away the human readable BDD layer and allowing the developers who are maintaining the test suites to use a real programming language with abstractions and composability.
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.
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.
I find that the "gherkin" syntax is not really expressive enough to express requirements in a way that is interesting for the business.
The business therefore always loses interest.
The business therefore always loses interest.
It is great for removing ambiguity, but business executives don't want to think on that level any more than they have to.
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).
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).
Disambiguation is precisely what it's not great at, I think. I would often see stories like "Given a logged in user..." and the details of what kind of user it was would be buried in a step definition somewhere.
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 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.
Those should be I don't care about it now - it should work for anyone.
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.
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.
>then it turns out that those business folks aren't really interested in it
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.
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.
I guess they're used to getting their way regardless of whatever language they express it in. After all, "holding the bag"? Developers are certainly holding one kind of bag, but since we're already talking about Cucumber, I don't think that expression necessarily means the same thing to all people.
That would mean they are accountable to something and that is dangerous to both incompetent and lazy people
I really liked using specflow (a cucumber equivalent) for dotnet years ago. It comes into its own when you want to quickly multiply up the cases or
build out scenarios from smaller steps. Even if you are unit testing and not using BDD it is useful. But it is
an investment, especially if you need to move exisiting tests to it. Being able to write code for a single step requires
decent decoupling through the test and tested code.
for .NET, LightBDD is much better than Specflow.
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.
https://github.com/LightBDD
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.
https://github.com/LightBDD
I have used Cucumber in various projects, but haven't yet had the pleasure of seeing it all work out.
- 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
I would advise against BDD/Cucumber and to be convinced otherwise I'd have to see a well though-out and realistic working example.
- 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.
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:
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: "[email protected]" }
assert_enqueued_emails 0
assert flash[:alert]
assert_response :unprocessable_entity
end
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.
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.
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 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.
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.
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)
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.)
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.)
[deleted]
> 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.
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.
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...)
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.
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?
[deleted]
I must say. Man is pretty chill for someone being just cut off without a word.
wonder what he made in the initial acquisition
Like many others here, I haven't used Cucumber in a while, but back when I did, I went a couple to workshops that Matt ran, exploring BDD.
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.
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.
[deleted]
I really like this chap's attitude, and I sincerely wish him the very best.
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.