I do find “BDD” a frustrating term. It was coined by Dan North [0] to refer to a coherent set of sensible TDD practices — give tests expressive names, say “beh

I do find “BDD” a frustrating term. It was coined by Dan North [0] to refer to a coherent set of sensible TDD practices — give tests expressive names, say “behaviour” not “test”, write executable “given/when/then” acceptance criteria — but in the intervening 16 years (!) it’s mutated into… I don’t even know what. There’s a community of “BDD” practitioners who talk about all sorts of ideas that aren’t necessarily even specific to software engineering. Which is fine and good, but it’s rendered the term essentially meaningless in a software context. These days I usually say “double-loop TDD” or “outside-in TDD” when I want to emphasise the use of executable acceptance tests; it’s impossible to predict what (if anything) “BDD” will mean to anyone. [0] https://dannorth.net/introducing-bdd/ https://dannorth.net/introducing-bdd/