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.
The reason I started talking about the behaviour aspects of TDD was *because
* I think it's such an amazing idea, and it was frustrating me that people I
was coaching didn't see that, and instead tied themselves in knots trying to
understand the complex domain of software testing. Then I realised they
thought that understanding testing was some kind of prerequisite to
benefiting from TDD, so that's when I tried just removing the word "test"
from the conversation altogether.
Liz is spot on when she says BDD is about understanding the customer's need
and letting her emerging understanding of that need drive the software she
writes (and being able to prove that with an evolving suite of acceptance
tests), while always assuming she doesn't quite understand what they want,
and therefore always trying to gain greater understanding. But I bet that's
what Kent Beck would say if you asked him what TDD was all about.
On 2 February 2011 12:29, Tom Janssens <d4sk...@gmail.com> wrote:
> I've made a comparison in the past, it's over on my blog:
> The key points:
> - when using BDD, you can start refactoring your app before
> implementing it, by refactoring the stories
> - once you define the behavior, it usually does not change anymore.
> Since BDD tests the behavior and not the implementation (TDD), your
> specs will probably never have to be changed.
> On 2 feb, 03:29, fatur rahman <mfat...@gmail.com> wrote:
> > The key principal is in D, Driven.
> > It's about driving not shooting.
> > rgds
> > fatur
> > On Wed, Feb 2, 2011 at 3:37 AM, Peter Bell <pe...@pbell.com> wrote:
> > > On Feb 1, 2011, at 11:44 AM, Dan North wrote:
> > > Outside-in is about imagining the as-yet-unwritten app is a black box.
> > >> <snip>
> > > Eventually you run out of turtles.
> > > Optimist.
> > > What if it really is "turtles all the way down"? :)
> > > BTW, loving the "deliberate discovery" content.
> > > Best Wishes,
> > > Peter
> > > --
> > > You received this message because you are subscribed to the Google
> > > "Behaviour Driven Development" group.
> > > To post to this group, send email to
> > > email@example.com.
> > > To unsubscribe from this group, send email to
> > > firstname.lastname@example.org<behaviordrivendevelo pment%2Bunsubscribe@googlegroups.com>
> <behaviordrivendevelopment%2Bunsubscribe@googlegroups.com<behaviordrivendev elopment%252Bunsubscribe@googlegroups.com>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/behaviordrivendevelopment?hl=en.
> You received this message because you are subscribed to the Google Groups
> "Behaviour Driven Development" group.
> To post to this group, send email to
> To unsubscribe from this group, send email to
> email@example.com<behaviordrivendevelo pment%2Bunsubscribe@googlegroups.com>
> For more options, visit this group at