What is the difference between Behaviour Driven Development (BDD) and Acceptance Test Driven Development (ATDD)?

Question

I'm writing a short paper to expound the benefits of unit testing and TDD. I've included a short section at the end entitled "Beyond TDD" in which I'd hoped to cover a few different approaches based on TDD, BDD and ATDD in particular.

I'm sort of familiar with BDD (I've played with SpecFlow) but after reading up on ATDD, it sounds very similar. Are BDD and ATDD just two names for what is essentially the same process - document the behaviours in a 'ubiquitous' language', generate an automated acceptance test suite, then go about making the acceptance tests pass?

Answer 1

While I agree generally with gishu's post, there are a couple of areas in which I disagree. In the IMHO section, he presents BDD specification as the user story specification developed by Rachel Davies et al: As a... I want... so that.

The BDD specification is Given... When... Then... as in

Given that the user is logged in, when the user clicks on x, then we should see Y.

This is about conditions, actions, and expectations, and is core to BDD.

ATDD is, as gishu suggests, the practice of driving development through the use of acceptance test specifications, implemented as executable acceptance criteria. The specification, in the BDD form, is neither required nor "best practice." In practice, however, it is effective in focusing the thinking and language on how to verify that the work has been done satisfactorily and meets requirements.

Note that BDD is not particularly based on TDD. ATDD is loosely based on TDD in that it is testing that is done before development is done. Beyond that, it is not focused on developer work, but on the overall direction and validation of the project. ATDD meshes well with Story Mapping, in that it plays well during the discovery phase when higher level requirements are being written, and it's important to know "how will we know when it has been done properly?"

Answer 2

BDD (Dan North, Dave Astels, Dave Chelimsky, et. al) is a movement to make the whole delivery process agile.

That said, teams doing BDD would be employing the practice of ATDD - i.e. the process of starting with executable specifications of acceptance criteria. An effective graphic to put the point across is where ATDD wraps the inner cycle of TDD.

ATDD is just the practice of starting with executable acceptance criteria before development and using it to shape the design of the underlying code base (much like TDD but at a more chunkier level).

What follows is totally an opinion and may not be entirely accurate: You could be doing ATDD but still not be doing BDD:

e.g. I could be writing automated acceptance tests but which are not readable.. which do not convey intent. I could be writing a comprehensive suite of automated 'regression' tests but which do not tell me what does the system does/ how does it work.

• BDD stresses on language and communication strongly. e.g. specifying behavior i.e. instead of saying

testXDoesY

BDD would specify it as

As a StakeHolder, X should do Y so that I can Z.

So to close, I think the major difference (which may occur but doesn't have to) is that ATDD could turn into a comprehensive automated suite that just acts as a target for active development + regression. BDD would implore you to move the needle further onto shared language between problem and solution domains + living documentation via executable examples that enables future constructive conversation