Behavior Driven Development

At the last Fargo Moorhead Developers meeting we had a great presentation from Max Pool about Behavior Driven Development. It sounded strangely like TDD. After the meeting I jumped online and researched it some. I wanted to post the links and important excerpts that provided me the most insight into this concept:


Dan North – Introducing BDD

I started using the word “behaviour” in place of “test” in my dealings with TDD and found that not only did it seem to fit but also that a whole category of coaching questions magically dissolved.

I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development.


Behavioral tests use the techniques of Test-Driven Development but have a more specific goal. The purpose is to define the behavior of an application rather than the implementation.

Testing before implementing is a crucial aspect of Behavior Driven Development.

Behavior Driven Development

It must be stressed that BDD is a rephrasing of existing good practice, it is not a radically new departure. Its aim is to bring together existing, well-established techniques under a common banner and with a consistent and unambiguous terminology. BDD is very much focused on “Getting the words right” and this focus is intended to produce a vocabulary that is accurate, accessible, descriptive and consistent.

In fact “Getting the words right” was the starting point for the development of BDD, and is still very much at its core, but the power of getting the words right has led to some insights and extrapolations that have helped us to better understand our approach and to extend it.


Test Driven Development isn’t brilliantly named, it hides the fact that TDD is a specification process, not a testing process.

BDD and NSpec have shed the test oriented terminology in favour of a specification friendly nomenclature.

public class Example
  public void BooleanSpecificationExample()
    Specify.That( someObj.SomeMethod() ).ShouldBeFalse();


Behaviour-driven development (BDD) is an evolution of test-driven development (TDD) and acceptance-test driven design, and is intended to make these practices more accessible and intuitive to newcomers and experts alike.

It shifts the vocabulary from being test-based to behaviour-based, and positions itself as a design philosophy.


Dan Pink (author of “A Whole New Mind”) has coined the phrase “A metaphor can be worth a thousand pictures”. My memory isn’t that great so I like to distill things down to a concept or metaphor. BDD is all about getting the words and metaphors right. It is a language that I’ll take a while to get used to, but after doing my best to explain TDD numerous times I can see the advantages of the behavior metaphor over the test one.


I’m really interested in using the specification language that Dan North was talking about… I’m going to have to give that a go…

Comments (2)

  1. Jared says:

    Wow, two years between posts.  Is that all you have to say?  🙂

  2. Chris Garty says:

    Hi Jared, thanks for noticing 🙂

    I moved to the Microsoft Dynamics AX Client team in February. Before that I had an ‘encouraged’ silence on my product (MBF then Dynamics Tools)… and I didn’t get excited enough about things unrelated to my product to warrant a post.

    This grabbed my attention strongly…

    I hope to gradually increase the amount I post now and when details of Microsoft Dynamics AX 5.0 start being released I expect to do quite a few posts related to that 🙂

Skip to main content