TDD vs BDD

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