Cucumber maintainer has been laid off
mattwynne.net
Cucumber maintainer has been laid off
1–10 of 81 posts
Re: Cucumber maintainer has been laid off
#213 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 :)
Re: Cucumber maintainer has been laid off
#3I 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.
Re: Cucumber maintainer has been laid off
#413 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 tho…
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?
Re: Cucumber maintainer has been laid off
#513 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 tho…
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...
Re: Cucumber maintainer has been laid off
#613 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 tho…
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?
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.
Re: Cucumber maintainer has been laid off
#7I 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
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.
Re: Cucumber maintainer has been laid off
#8I 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…
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.
Re: Cucumber maintainer has been laid off
#9I must say. Man is pretty chill for someone being just cut off without a word.
Re: Cucumber maintainer has been laid off
#10I 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…
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 uni…
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?".