Backstory: Last month the Weekend Testing Toronto group met to discuss Behaviour Driven Design (BDD) - our experiences with it, its benefits and drawbacks. Our fearless leader Albert Gareev posted an experience report and the comments brought up a common conflict: "BDD vs Acceptance Test Driven Development" (ATDD). Commenters agreed that ATDD has less overhead than BDD, though they accomplish the same general goal. I struggled to agree with them, because I couldn't see the difference between BDD and ATDD. Maybe there isn't one.
What are BDD and ATDD?
I've never seen a canonical definition for either of these terms, so for safety I'll lay out my own. These are the crux of my argument.
Behaviour Driven Design - When designing a product, define a set of behaviours which that product must satisfy. These are usually in the format "Given some preconditions, When a specific event occurs, Then a specific output should occur". These behaviours are defined in a collaboration between all stakeholders of the product (or as many as possible).
Acceptance Test Driven Development - When designing a product, define a set of acceptance tests which the product must satisfy. These behaviours are defined in a collaboration between all stakeholders of the product (or as many as possible).
Is there a difference?
There are two differences between those definitions. "Behaviours" versus "Acceptance Tests", and ATDD does not typically use "Given, When, Then".
Behaviours versus Acceptance Tests: I think it's safe to say Behaviours are Acceptance Tests. They both define some input and expected output on the final product, and they are both evaluated to determine if the system is working properly. It doesn't matter whether that evaluation is executed in code, or in the mind of a reader.
ATDD not using Given, When, Then: ATDD may use GWT syntax, but it's not necessary.
Combining these two points, I think BDD is an implementation of ATDD, using a specific syntax.
Choosing a Design Process
If you're looking for the benefit of collaborative design, I'd recommend choosing ATDD as a general process, and then picking a syntax which fits your needs. BDD is just one option and there are many others.
BDD's Given When Then syntax has the benefit of being very simple, but can also become quite wordy. Good for non-technical stakeholders, bad for technical ones who don't want to waste time.
Tests could instead be defined in something closer to raw code - gaining efficiency but requiring more technical knowledge from the reader.
Another option could be to use minimal, pure-english or shorthand tests and trust all stakeholders to simply fill in the blanks for themselves. Very quick in tight-knit teams.
Takeaway
BDD is just one implementation of ATDD. If you're considering adopting BDD, I'd suggest you first look at adopting ATDD and then choose a syntax which fits your team's needs.