One of the sessions at ADC2011 that I understood (even though it was in German), was Bjorn Rochel’s talk on test organization. Bjorn told a story of the evolution of his experience writing tests, and how to organize them. For example, he started out with a test class, called CalculatorTests, and every method name ended with Test. Not so different than how I wrote tests initially.

As his story moved forward in time, he moved from per-class tests to BDD (behavior driven development) style tests. He compared the AAA (Arrange-Act-Assert) structure to the GWT (Given-When-Then) structure, that are similar in essence but still different. For example, as you add more tests, you’ll arrange them differently than the regular per-class tests.

I’ve tried to like BDD in the past, but could not see the main benefit over TDD. It still seems to me a more technical difference, rather than a new way to write code. Bjorn suggested something that has helped me accept the BDD style. Slightly.

In the GWT world, G,W, and T are separate methods. That means that “all you need” is to fill in the blanks. I agree that this kind of structure can help newbies with their first tests. In the AAA version of the same tests, all three parts basically resides inside the same method. Since I put more emphasis on test readability than anything else, my feeling is still I rather put everything under one method, rather than scroll up and down to see what the test does.

I’m still thinking about the how many tests are organized in a solution in BDD – they are centered around a feature, not per class. I’m inclined to put stuff (not just tests) where I think I’ll look for it in the future. For tests, using from the class code as a starting point, is the natural thing to do. Am I going back to my AAA comfort zone?

Time will tell. I’m planning to revisit BDD more and try to see where it can help more.

What about you? Which do you prefer and why?

4 comments on “TDD vs BDD”

  1. Lior Friedman: Reply

    I think you might be missing a key aspect of BDD.
    BDD is many times used for the bigger kind of tests. i.e. E@E / Acceptance tests.
    iI don’t think that its TDD Vs BDD.

  2. Gil Zilberfeld Reply

    At first, I thought this was the case – that they are not even comparable.
    However, I’m reading more about BDD used at a lower level than the full acceptance level.

    Just like unit tests is not confined to the object level, there’s a wider band of options, that BDD can also take place.

  3. Lior Friedman: Reply

    But when you bring BDD ‘down’ to the unit test level its not a different practice. just an alternative syntax and terminology.
    The same btw is true when you pull TDD to ‘higher’ levels. You get a nice syntax/tool to write bigger tests.

    The real benefit from doing BDD in my opinion is the ability to bring more stakeholders other than the developers into the mix (Testers, product,…). Creating a shared language for all to share and communicate with. I’m still contemplating if that make sense when diving into unit tests. Do I as a programmer really want/need to bring those stakeholders to that level?

  4. Gil Zilberfeld Reply

    I expect with tools like MSpec or SpecFlow the language makes it easy to non-coders to share the understanding of intent.

    However, lower level tools like NSpec or NBehave cannot reach this goal. they are too code oriented.

    For unit tests, in general, I would not want to describe everything to the whole world. But, if that’s my only tool, and no body else is making the effort to bridge the gap between the developers and the business stakeholders, maybe that would be a good start,

Leave A Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: