The unit test is dead.
Long live the integration test.
🥒 reigns supreme
Discussion
Gherkin was always amazing, but the amount of mileage you get out of it, when using an LLM to code, is astounding.
The ultimate 'context engineering' I guess.
I need to get back into Cucumber. It's been a while. Like a decade or so. đź«
Here's the thing I've discovered, that makes using Gherkin+AI so awesome:
You don't need to automate the Gherkin.
Just write the .feature files in high detail, and then skip the steps. And then just ask the AI to make sure to check against the Gherkin. And, if you want something changed, just adjust the Gherkin by hand and ask the AI to implement the changes to match the new description.
The models _are_ the test automation.
It's like you architect a software bluebrint and the AI is the builder.
And, after it builds things, you can go in and rearrange everything, to your liking, and then say, "I changed the code. Please double-check that I didn't break the features," and it'll go through and mark everything that conflicts.
And, if you get tired of your code, delete the entire /src/ and say, "Please generate all of the code to implement the .feature tests." and it'll write it all out, neatly, in 5 minutes.
This is the way.
Code is disposable.
Creativity and some discipline in getting thoughts down coherently is where the value is now.
Wild.
The code is disposable is actually turning into a software architect's dream, which I didn't see coming. As he can use a prototype to hone the behavior, and then generate lots of different implementations to fulfill the behavior, and then pick the one he likes best and architect it even harder.
Prbly worth getting AI to write the gherkin from general handwaving and refine from there.
Gonna give this a try.
I wrote a design document, including PlantUML diagrams, and mockups, and hyperlinks to designs I liked and specs I wanted to cover and architectural/quality concepts I wanted to include, and coding guideline stuff from our PO. It was like 5 pages long.
And then I had it generate the .feature files, and went through multiple iterations on each file, editing and then having it review-and-suggest-more, and basta. The team has been feeding me their wishes, on the side, in Gherkin, and I just say "Please incorporate this into the .feature files and then implement." and ta-da!
Super powerful and also should stop most of the ai hallucination.
Yes. I actually always say, "You might have made some stuff up. Please go back and check against the features." and it actually corrects any hallucinations, itself.
What you get out is not a product, but it's a highly-functionality prototype. You can then hone it and refine it. Once it gets relatively good and everything basically works, you can hand it off to your architect (or architect it, yourself) and he can rewrite the code.
He can even open a new repo, copy-paste in the .feature files, and then build a completely new, clean software program that passes the same tests.
The key is that you hone it and refine it OVER THE FEATURES, never directly in the implementation. Otherwise, the business logic gets wiped out, when it changes code. You have to hard-break between the behavior and the implementation.
If you write (or generate) your code defensively and with high granularity, and then have extensive, clear Gherkin .feature files, then you probably don't need unit tests, or you should focus more on unit tests over bigger units.
100% coverage = 0% coverage
Few.
Your functional design patterns are flawed then.
The whole point of BDD is that you don't have any functional design patterns. You only define the behavior the user experiences. Any function that can delivery the same user experience passes the test.
The AI models are intelligent enough to determine this, on the fly, now, even if the implementation is constantly in flux, so you can get rid of any brittle test.
While BDD focuses on specifying user-facing behavior, dismissing functional design patterns altogether is a dangerous oversimplification. Functional design isn’t about rigidity, it’s about clarity, predictability, and composability. It creates a stable foundation beneath the behavior, enabling you to write code that’s testable, maintainable, and resilient to change.
Yes, AI models can adapt to varying implementations, but that doesn’t mean we should throw away architectural discipline. Relying solely on AI to interpret shifting implementations ignores the real-world complexity of systems where behavior is emergent, not always deterministic. Functional design provides the deterministic scaffolding needed for robust software so your “green tests” actually mean something beyond the surface.
BDD and functional design aren’t at odds, they’re complementary. BDD defines what the system should do. Functional design ensures how it does it remains understandable, correct, and evolvable. Without structure, your tests pass, but your system becomes a black box, opaque, fragile, and eventually untestable.
