Behavior Driven Development (BDD) has been a pretty big topic in some of the email groups I lurk in.  I'm seeing BDD cast as a whole new paradigm of development, where as I see BDD as an evolution of TDD with a better syntax and mechanics for expressing the desired functionality with tests/specifications.  That's more than enough advantages to jump into BDD and plenty to be excited about, but not enough to designate BDD as a whole new paradigm.  Andy Glover described BDD as TDD Done Right and I concur.

Part of the impetus to move to BDD is appealing to people who were always turned off by TDD.  That's great, but I'm seeing people trying to skip the "driving a design through unit tests" discipline part of TDD to skip right to executable requirements at the acceptance level.  Jeremy, you might say, that's just some useless terminology from Agile yesterday that we need to let go of!  That's not baggage so much as it's a set of hard lessons learned. 

Any testing/specification is better than no testing/specification, but in 4+ years of practicing TDD I've learned over and over again that it's more efficient to write fine-grained unit tests first before proceeding on to making the acceptance and integration tests pass.  It's great to have the business facing tests/specifications written before coding, but you don't work with them until you're reasonably confident from unit tests.  It's all about the feedback cycle and reducing a big problem into small, manageable parts.  It's easier to shake out most of the problems with the code at the unit level first than it is to try to code up to a big coarse grained test first.  If you try to skip right to coarse grained tests you're likely to spend some time in debugger jail.  I'll scream until I'm hoarse that it's best, and even more efficient in developer time, to do multiple levels of testing instead of only coarse grained tests.

Besides, if you want to know how to code in a way to make BDD succeed at both the unit and acceptance levels, you're going to end up learning almost all of the lessons we TDD practitioners have already faced.  Don't even think about ditching all of the TDD design lore when you move to BDD.  Besides, those cool executable requirements specifications in xBehave?  They'll work a lot smoother if your code is testable (loosely coupled, highly cohesive) and there's already quite a bit of lore on how to do that in the TDD canon.

How many of these Double D's do I need?  How "Driven" must I be?

While technically you need zero of the Double D's to deliver working code, many of the xDD practices and methods are quite complementary.  Rebecca Wirfs-Bock has a nice summary of many of the Double D's.  I'll take my own crack at how the Double D's are different and where they complement each other:

• Test Driven Development / Behavior Driven Development - Low level design, unit testing as well.  Should lead to low level specifications for the code, especially with BDD.
• Acceptance Test Driven Development - Capturing business requirements as executable tests.  Do NOT confuse this with TDD/BDD.  Not all that common in practice, but highly advantageous.
• Responsibility Driven Development - A design technique that puts an emphasis on the assigning of responsibilities to the consituent classes in an OOP system with plenty of terminology for identifying and classifying responsibilities.  I think RDD is a perfect complement to TDD/BDD because of its lightweight nature
• Domain Driven Design - The Domain Model pattern done right for logic intensive systems.  DDD is also a natural ally of TDD because it leads to a system that's far easier to drive through unit tests than a traditional n-Tier system written in a procedural Transaction Script style.  RDD is also a natural complement to DDD to help guide the assignment of responsibilities between entities and services.
• Model Driven Development - I threw this one in just to be complete, but it's coming from a completely different world view than the other Double D's, and I've always been dubious on this one.  I suppose DDD could easily be combined with MDD.  I used to worry that I was in danger of missing the boat if it really took off, but that thought hasn't crossed my mind for years.  Go make up your own mind.