“Getting stakeholders involved in the design process” is giving me BDD flashbacks. It’s Gherkin all over again.
But then there are always people that look at those and keep exactly the bad parts. Like the links from the article, that all but define event-driven architectures as software that use Kafka.
Two weeks ago at my new workplace I sat through a colleague's tech talk about how to test with Cucumber.
Its not that it makes testing easier, its that, in the right social context, it makes testing more likely to be aligned with business intent.
B) that extra layer of translation, when combined with a multitude of different people who refer to or model different things in different ways is going to devolve into the Tower of Babel, and you'll soon find yourself in step level meta-hell trying to bridge in new cross cutting abstractions into huge swathes of code that will break for reasons that seem entirely irrelevant to the hackneyed step grammar.
C) Seperation of Concerns: Writing English/Natural language to be understood utilizes a fundamentally different approach to Authorship than does code authoring. Write code that works, then. Explain it with comments. Do not use DSL's because then you're just adding writing a parser layer on top of writing a test framework that works.
D)If I see one more spelling mistake I'm going to....
BDD is doable. As a testing professional though, I always emphasize the parts wherein the work is packaged and delivered in entire flows rather than on using a tool like Cucumber and making my testers suffer through writing English for people who will never look at code, even if you threatened them with bodily harm if they didn't.
Do what works for you though. I find it works okayish for integration or system level testing... But it's way to heavy for anything else.
Devs are already doing this with adding comments with Github copilot .. might be an interesting way to close out the loop without putting too much process in.
So you're asking the computer to look at bones, and vomit forth a description of just WTF you were trying to do in the first place, when the same set of primitives, configured in the same way, could solve problems in thousands of different contexts.
There may be more success going the other way: distilling the config of primitives from the messiness of requirements; which strikes me as something similar to what is called a prompt engineer; however, the biggest difference there is the additional burden of cutting through BS.
I have an idea!
Lets refine that.
The device must... The device must not...
There we go.
I've recently introduced Cucumber and it's been an incredibly useful framework for collaborating between developers and product owners. I'd recommend "Writing Great Specifications" by Kamil Nicieja.
It shines the most in gnarly login/sign up flows that always evolve into all kinds of weird edge cases over time.
Yeah, its good to point out that the people who need to think in Business Requirements rather than implementation detail terms are, often the same people, at different moments, especially on smaller teams (or teams that do something closer to Manifesto-and-principles-Agile, rather than bureaucratic-cargo-cult-Agile.)