BDD, TDD, and the other Double D’s

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

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Test Driven Development. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Neel

    A lot of BDD is TDD done right, certainly. I feel there’s more though and it’s in the collaborative process that it encourages and grammar that it recommends for the stories.

    The details are here:

  • Jeremy D. Miller


    I’d say that code coverage is just one more statistic. It tells you something about the code, but should never be taken at face value. I don’t unit test getters & setters or constructors, and certainly wouldn’t waste anytime just to make my coverage numbers better when that doesn’t add any real value.

  • raveman

    what you guys think about code coverage ? so many people are so proud of have 90-100% of it, you will kill them with BDD now 😛 i almost always did BDD, TDD is cool to look at, but having any code coverage is just stupid to me. always remind me of code sample i saw once – it was testing setters and getters in bean.

  • Christopher Bennage

    On a slightly different note, my wife (glancing over my shoulder) had a rather different take on the meaning of “Double D”. Needless to say, she was very curious to know what kind of blogs I was reading… :-)

  • Jeremy D. Miller


    I’m drawing up a bit of a response. I don’t disagree with you at all, I’m just concerned that we still need to be cognizant of the different levels of granularity for the specifications and the importance of having the different levels.

    What I was trying to do with the section on the xDD’s was talk about how all these things are complementary instead of either/or propositions. I was actually *trying* to reduce confusion.

  • Nat Pryce

    I have to completely disagree with your definition of TDD. The fundamental basis of TDD is that you drive all development from tests. That is, you don’t write anything without a failing test. That applies AT ALL SCALES OF THE SYSTEM. So, you don’t start working on a feature of the system without a failing end-to-end test that exercises that feature. Once that test is written you can start changing the system to make the test pass. When doing that, you don’t start working on classes in the system without failing unit tests that shows what the classes should do, and you don’t write classes that they need without failing unit tests, etc. etc.

    A lot of people do not understand what TDD is and it does not help encourage the take up of TDD to misrepresent it like this and confuse the issue by introducing a lot of other “xDD” acronyms. It’s unfortunate that a lot of books concentrate on unit testing only, but that’s probably because you can describe unit testing in a way that applies to everyone’s project while the way one writes acceptance tests is specific to each application and so much harder to turn into a best-selling book.

  • Kevin Williams

    I personally insist on referring to TDD and BDD as Test Driven Design and Behavior Driven Design. This resolves the issue of people trying to skip the “driving a design through unit tests”, at least in my experience.

  • Jeremy D. Miller

    I’m more of a Bill Engvall / Ron White fan myself Jay. You can have Larry the Cable Guy.

  • Jay Kimble

    You missed one!

    GRDD or GrDD or….

    I know I drive you guys nuts…

  • Ian Cooper

    I have to agree that I see BDD as a part of the whole, not a revolution, that speaks to a better way to organize acceptance tests. Like you my experience would suggest that you need to favor TDD with unit tests over starting with the customer acceptance tests, because you get the granularity all wrong otherwise and will find your tests end up being fragile and don’t narrow down to errors enough. I’d rather see unit tests and customer tests as separate patterns within an xUnit testing whole than as some kind of revolution.

  • Shane Courtrille

    Can you give a list of email groups you find have value that are public? Thanks.