Another question that people often ask around or to me is, “What’s the difference between Acceptance Test Driven Development and Behavior Driven Development?”
To explain, I’ll go back to the time when I first learnt BDD.
BDD started at a unit or class level
Dan North started doing BDD at a unit or class level, as a replacement for TDD – a mechanism for describing the behaviour of code and providing examples, without using the word “test”, because it turned out that this clarified a lot of the confusion (and I still find it much easier to teach TDD if I avoid the word “test”, whatever I subsequently call it).
It was only when Chris Matts said, “That looks quite a lot like analysis,” that Dan began taking it out to describe the behaviour of whole systems of code.
ATDD practices at the time weren’t all that solid
When I came across BDD (late 2004), I was working on a project which had been driven quite heavily with ATDD – at least to start with.
This project had 160 acceptance tests. They all consisted of lists of text boxes, button clicks, locating more text boxes and repeating until a particular outcome was reached. They were lengthy. They were rigorous. Unfortunately, at some point someone had introduced a dialog box into the flow, disrupting about 30% of these tests. There were another 10% also failing, possibly for similar reasons.
It took a couple of days for two of us to work through them, fixing the tests. We got most of them working, but not enough for anyone to actually care about them. The acceptance tests were making things hard to change.
BDD changed the landscape
Dan has since said that JBehave was “just a thought experiment”, and he didn’t really expect anyone to use it. (That’s good, because it JBehave 1.0 was pretty unusable, at least at a scenario level). It worked as a thought experiment, though, and lots of people started doing ATDD in a very different way – creating examples of how their system worked, and using those examples to explore the scope of their systems as well as the responsibility of their classes. Lots of people started working outside-in, from the UIs through which users experienced the system’s behaviour, to the controllers, the domain models, the utility classes, services, repositories, etc., until they finally had working software that tended to matter more to the stakeholders of the project than software had before.
Dave Chelimsky’s movement over to plain text really helped this movement to take off. When people think of “BDD” they often think of the frameworks which have copied this (Cucumber and JBehave 2.0 amongst them), even though this isn’t the complete story. They have certainly encouraged developers – famous for their introverted natures – to boldly go into the analysis space.
BDD enabled conversation
Whether through frameworks, DSLs or just conversation, the biggest difference between BDD and ATDD was the way in which BDD enabled a common language between users and business stakeholders, because it supports Domain Driven Design’s “ubiquitous language” (forgive the rabbit-in-the-headlights look, it was my first ever video!), and provides its own ubiquitous language for software development – the language of examples and behaviour, rather than tests and acceptance criteria.
The second difference was the reusability of steps. This is something which a lot of BDDers are still struggling with, so we’ve still got a way to go here. (More on steps and business / system capabilities some other time).
BDD doesn’t just stop at scenarios, it goes all the way to the project vision
Finally, Chris Matts introduced Feature Injection, which takes BDD’s patterns all the way into the analysis space.
(I consider Feature Injection and BDD to be children of Deliberate Discovery (even though they preceded it), which is itself a child of Real Options. I summarise Deliberate Discovery as the act of wilfully addressing ignorance. Both Deliberate Discovery and Real Options have implications and uses beyond software development, and I heartily recommend coaches and managers to go read up on them. In fact, everyone who lives a life of any kind of uncertainty should go and read up on them. And if your life is staid and comfortable, maybe it will help you to step into those challenging spaces. Go do it anyway.)
Or at least, this used to be the difference…
So that’s the past. What about now?
Well, most people who do ATDD nowadays use the Given-When-Then template which Chris introduced (shout-out to Gojko Adzic for his work in this space). They use domain language in conversation with the business. They’re interested in discussing what software would actually make a difference, then capturing that and sometimes automating it, with a focus on working out the software which would matter.
I’m guided by Dan’s words to the BDD Google Group, which apply both to TDD and ATDD:
I think you can over-think these things.
I’d like to avoid “BDD is better than TDD because…” or even “BDD is
different from TDD (as originally envisioned) because…”
TDD is amazing. Its initial conception was to solve exactly what I’ve been
trying to do with BDD. Originally it was described as variable scope (i.e.
covering both the space of modern day TDD-in-the-small and what the ATDD/SBE
folks are doing in the functional testing space). It’s not the *only* way to
come up with good design, and neither is BDD. They’re just both useful to
have in your back pocket as you go around trying to write decent software to
solve useful problems.
They’re called different things
The difference is that one is called Behaviour Driven Development – and some people find that wording useful – and one (or two) is called (Acceptance) Test Driven Development – and some people find that wording useful in a different way.