8

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?

Edu
  • 2,017
  • 17
  • 23
zekesteer
  • 133
  • 1
  • 5
  • possible duplicate of http://stackoverflow.com/questions/4395469/tdd-and-bdd-differences and http://programmers.stackexchange.com/questions/135218/what-is-the-difference-between-bdd-and-tdd – k3b Aug 16 '12 at 11:36
  • possible duplicate of [What are the primary differences between TDD and BDD?](http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd) – Don Roby Aug 16 '12 at 11:38
  • Thanks for the links but those posts cover the differences between TDD and BDD. I'm interested to know what the differences are between _ATTD_ and BDD exclusively - assuming ATTD and TTD are different (which I understand to be the case). – zekesteer Aug 16 '12 at 12:03
  • small one, ATDD instead of ATTD – Larry Cai Aug 31 '12 at 09:42

4 Answers4

9

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?"

Doc List
  • 91
  • 2
5

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

dialex
  • 2,706
  • 8
  • 44
  • 74
Gishu
  • 134,492
  • 47
  • 225
  • 308
1

ATDD is often used synonymously with Behavior Driven Development (BDD), Story Test Driven Development (SDD) and Specification By Example. The main distinction of ATDD compared to other agile approaches is, its focus on making developer, testers, business, product owners and other stakeholders collaborate and come up with a clear understanding of what needs to be implemented.

I personally like the concept of ATDD as it aligns with the “Shift Left paradigm” where development and testing should start as early as possible in the SDLC. It helps to bring more visibility into automation as we start writing automated tests right from the beginning of the SDLC and in turn helps in increased collaboration within the team.

Remember, ATDD is not one all-fits-all kind of solution. It is one of the agile approaches. There are various other ways to help to improve processes in teams but I specifically found this approach to focus on better acceptance tests and most importantly its emphasize on collaboration; which is the integral part of this approach.

halfer
  • 19,824
  • 17
  • 99
  • 186
Raj Subrameyer
  • 422
  • 4
  • 6
0

I would say that nothing much. My first assumption would be that ATDD, BDD, specification by example, agile acceptance testing, etc. all mean the same thing. If someone uses these terms so that they would mean separate things, they better explain the difference in that context.

Edu
  • 2,017
  • 17
  • 23