BDD (Behaviour Driven Development) is a synthesis and refinement
of practices stemming from TDD (Test Driven Development) and ATDD
(Acceptance Test Driven Development). I will write about ATDD in next
BDD augments TDD and ATDD with the following tactics:
apply the “Five Why’s” (if you don’t know what it is go to Start with Why)
principle to each proposed User Story, so that its purpose is clearly related
to business outcomes thinking “from the outside in”, in other words implement only those
behaviors which contribute most directly to these business outcomes, so as to minimize waste
describe behaviors in a single notation which is directly accessible
to domain experts, testers and developers, so as to improve communication
apply these techniques all the way down to the lowest levels of abstraction
of the software, paying particular attention to the distribution of behaviour,
so that evolution remains cheap
– See more at: http://guide.agilealliance.org/guide/bdd.html#sthash.zMCUfWLT.dpuf
Test-driven development focuses on the developer’s opinion on how parts of the software
Behavior-driven development focuses on the user’s opinion on how they want your application
The name test-driven development also caused confusion. How can you test something that’s not there yet?
It was Dan North 1 who noticed all these unsolved questions and came up with a solution: He suggested
that instead of writing tests you should think of specifying behavior. Behavior is how the user wants
the application to behave.
When your development is Behavior-driven, you always start with the piece of functionality that’s most
important to your user. I consider this phase as taking the developer hat off and putting the user hat on.
Once you’ve specified the user needs, you put the developer hat back on and implement your specification.
If you are interested to dig more deeply on BDD you should visit http://dannorth.net/introducing-bdd/