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.
Liz Keogh, lunivore 
Pingback: Don’t Defocus BDD | Stories from a Software Tester
Thanks for this Liz.
We currently use the terms TDD & acceptance tests but after reading Gojko’s Spec By Example, I’m trying to see if we can firm up the lingo we use.
Its great to have one post outlining each of the terms currently being bandied around.
I also like the links to Real Options & deliberate discovery – 2 other avenues I’m currently exploring!
Hi Liz, Some interesting points. I’m glad to see I’m not the only one to arrive at the conclusion that it’s just about who we’re communicating with and what terms matter to them.
To help remind you of what I said… it’s from 51:55 in this video:
http://skillsmatter.com/podcast/agile-testing/bdd-atdd-tdd
I also conclude in that video that the difference doesn’t matter – as long as we’re delivering products that matter.
All the best,
Antony
Pingback: Impressions from ALE2011—Day 1 « OlafLewitz
Pingback: Testing By Any Other Name… » Stories from a Software Tester
Pingback: We already use scrum – why do we need Collaborative Business Ownership? | Improve on Quality
Pingback: Liveblogging from Agile on the Beach | working with devs...
Hi Liz Keogh,
First of all, I love your work 🙂 However, I must disagree.
The difference is very much apparent once you start using ATDD platforms (Robotframwork) vs BDD frameworks (Cucumber). Moreover, the difference is not on the technical side but on team dynamics.
ATDD empowers QAs and BAs to write tests themselves. That’s because they can write the tests/specs and at the same time implement them.
BDD on the other hand requires the triage of BAs, QAs and DEVs (or at the very least DEVs and BA / QA). That’s all good, but it just lacks the empowerment of ATDD for BAs/QAs to implement the specs. This is also one of the reasons why I say BDD is dev centric. Even the paradigm is different. QAs are used to procedural workflow on their test cases (i.e. Login, then go to this page, then fill up form, etc). Doing BDD though (again) requires you to do a declarative approach (Given-When-Then). Sure you could bastardized it into procedural, but that’s not really the point is it? 🙂
Furthermore, BDD can be used both for black box and white box testing. ATDD is usually strictly blackbox 🙂
Lastly, i see ATDD more as automated functional testing. While BDD is more like the marriage of DDD and TDD 🙂
Cheers,
Franz See
Franzsee, in the period I’m writing about (2004ish) neither RobotFramework nor Cucumber existed. JBehave 1 was very, very different to JBehave 2, which is much more like Cucumber in how it works.
While ATDD does empower QAs and BAs to write tests themselves, those of us who were doing it well were doing it by having conversations with people, or at the very least verifying that our understanding was correct. I tend these days to suggest that the devs write the scenarios down just to get feedback on their understanding before they go off and implement the code, but even back then, it was often the devs implementing the scripts.
I also disagree that BDD is white box. It should be black box, particularly if you use declarative language as we recommend. In fact, the whole emphasis I place on “pixie driven development” is intended to bring out that “black box” element; it’s about what the magic pixies in the machine do, not how they do it.
ATDD is frequently about functional testing, but it shouldn’t be. If that were the case, you would be able to write the tests after the code. Both BDD and ATDD, done well, have an emphasis on conversation; on questioning of responsibility and capability; on a search for more examples, or scenarios, or tests, that break the understanding we build together. If you see ATDD more as automated functional testing, you may benefit from having some of those conversations first… we did!
Pingback: TDD vs BDD vs ATDD | Testing en Español
Hello Liz,
I have been exploring BDD, ATDD practices and per my understanding, we have conversations first discuss/write the scenarios (could write tests) and then implement the code. Is that correct?
I am asking this because I am seeing many many articles from people on LI saying – we write the tests after we write the code. This has been raising an alarm for me and I want to share with these people what the right way is.
Your last para above seems to send that message. Do you have any other posts (from you or Dan) where it’s clear about what comes first Conversation, scenarios, tests or code?
I would like to share that with the world.
Thanks,
Sameer
Hi Sameer,
Have a look at some of my more recent work on Cynefin, which will help here.
You will always, always want to have conversations first. If it’s easy, they’ll be quick. If it isn’t, you’ll be glad to have them.
As a quick guide: if you’ve never done it before, you’re going to be exploring a lot more than normal, so you’ll want to try something out until you understand it. Once you understand it, throw the prototype away (unless you’re *really* good at refactoring) and rewrite it in a production-ready state, including automating scenarios before the code if you can.
If you’ve done it before, or you have access to someone else who’s done it before, write the scenarios down first, before the code. You may also consider automating them before the code. It’s a good thing to do if you can.
If everyone’s done it before and it’s really boring then look for a library. open-source or off-the-shelf solution if you possibly can. If you can’t find one then write one, but get it out of your build. Your scenarios can either describe the behaviour of your solution directly or use a toy application to show other people how to use it. For boring scenarios it’s often enough to name them and be done with it (for instance: the one where we create a user, the one where we update a user, and the one where we delete a user).
Regardless, try avoiding the word “test”, which I think may be causing some of the confusion. If you think of them as examples of how the code behaves, or how the system behaves, then it should be easier to work out whether you can write those examples down, and easier to work out if you can automate them.
An awful lot of people start their TDD or BDD journey by writing examples scenarios down before the code, but automating them afterwards. That’s not the ideal, but it’s a pretty good way to get started when you don’t know what you’re doing, and I like it when people start that journey, so it’s OK by me.
Hope this helps! This blog post is quite old now (5+ years!), and I wrote it before I knew about Cynefin, so some of my newer BDD stuff is probably better than this.
Pingback: BDD Addict Newsletter June 2017 - Gáspár Nagy on software
Pingback: TDD, BDD, ATDD,sus orígenes y diferencias | Desde el bastión
Pingback: Development processes (Toolbox #6) - The Geeky Gecko