I tried the EventStorming a few years ago with a dept for working out a new system , it was really eye opening how everyone referred to things - seeing it all laid out made them realise they all did things slightly differently, and referred to things differently. It was fun and very useful to not just me, but them as well

“Getting stakeholders involved in the design process” is giving me BDD flashbacks. It’s Gherkin all over again.

haha, weren't they meant to be writing the tests by now?

I was happy that we got rid of Cucumber at my workplace in 2018.

Two weeks ago at my new workplace I sat through a colleague's tech talk about how to test with Cucumber.

A bit naviely using cucumber seems like a good idea. Could you share some advice or resources on why it might not be ?

You're setting up an extra layer of difficulty around the system. Sure, the English is 'easy' to read, as long you do the hard work of converting the test cases to English. Then when something goes wrong or you want to know what's really going on, you have to translate from English back into the system's language to think about it.

The utility of Cucumber, it seems to me, is that it makes it more likely that the business level description of the test cases is maintained in sync with the technical implementation, which (if the test cases aren’t squirreled away in the tech team away from the eyes of people responsible directly to customers) makes it less likely that you experience drift between what you are testing and what users rely on the system to do.

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.

Not only that, but it enables product owners to actually express the features they want, in such a way as they can be implemented. Without that devs and product owners tend to second-guess each other.

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.

I own several apps that I wouldn't be able to maintain by myself without good end to end tests. The nice thing about cucumber is I can come back to a test a year later and instantly understand what it's testing for at a requirements level vs. having to reason through the gnarly details of what it actually does, then work backwards to the original requirement.

It shines the most in gnarly login/sign up flows that always evolve into all kinds of weird edge cases over time.

> The nice thing about cucumber is I can come back to a test a year later and instantly understand what it’s testing for at a requirements level vs. having to reason through the gnarly details of what it actually does, then work backwards to the original requirement.

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.)

A) Business will never read your tests. Whatever you are smoking that has you thinking they will, stop it. A.5) In the event they do, they will never extract the nuance of the glue.

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.

I pretty much agree with you. Do you think there would be any value in having some sort of integration that goes the other way - scan existing test suite code and converts to natural language for surfacing to the business?

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.

That ones tricky, because most of computing is composing primitives distilled out of the ambiguous mess of a business context. Your implementations are the bones of process left when you've peeled back the skin, cut out all tha musculature, and removed anything resembling a squishy bit, just leaving a skeleton.

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.

yeah, in the case of the second approach it might have to be more of a dialog than a one of translation from requirements, in the same way you might have a dialog with chatGPT to clear up ambiguity.

It's basically the loop of QA tbqh.

I have an idea!

Lets refine that.

The device must... The device must not...

There we go.

Maybe they'll get ChatGPT to write them for them.

Maybe we will?

The good parts of SOA, the event and CQRS stuff, data administration (and curation recently), and BDD all reduce to the same set of ideas.

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.

> I see we're rebranding SOA/microservices again.

The rebrandings will continue until morale improves.

I don't think I can upvote this hard enough. Getting people to think and talk about what they do in context provides a lot of great insight in how to use tech (or not use it) to solve their problems.

I agree, but I've experienced quite often people refusing to care about context. Often some variant of "I don't know about that, I only do X".

Or “I have to X, Y, and Z. To get the result I want.” Only to find out X and Y haven’t mattered in years and they only do it because it’s on the form.

Well that's rote learning for you, but I don't think it's the same issue as people avoiding knowing about context. I've met very smart people who know their silos quite well and refuse to acknowledge any picture bigger then they need to, strictly speaking.

I disagree. EDA is about how microservices are integrated and, if you establish it, how consistency between them is maintained. Note the talk of ordering guarantees and the like. See also event sourcing and the shifting of responsibility for maintaining data stores: historically data stores were maintained by an authoritative microservice while in many EDA systems multiple copies of the same data stores exist across the system.