Does BDD replace or augment TDD?

Question

Does BDD replace TDD, or are both used together? I've been reading that BDD should only test for things that the user can see. If that is the case, does that mean one would need to use TDD for service methods that the user wouldn't see?

Answer 1

BDD is a replacement for both TDD and ATDD (and derived from them).

The first ever tool for BDD, JBehave, actually started as a replacement for the unit-testing framework JUnit. The intention was that it would allow you to describe the behaviour of your (not-yet-written) system and provide examples, without using the word "test", since really at that stage it's analysis, not testing. That word, "test", was causing all kinds of confusion!

The difference is that example and behaviour and specification are all problem-space language, whereas the word test is solution-space. It tends to make people think they understand the problem, and are testing a solution, which is a problem, if they really don't!

It turns out that avoiding the word test helps people to explore the problem more fully. You can read about this in Dan North's original article.

While Dan was exploring BDD in 2003/4, he explained it to Chris Matts, who was working at the time as a Business Analyst. Chris said, "But that's just like analysis!" And so they started exploring how Chris did analysis on whole systems, and how examples of that worked, and Chris realised that it wasn't just about behaviour and outcomes, it was about behaviour and outcomes in a context. That formed the whole "Given, When, Then" syntax that we now know today (it wasn't called Gherkin back then because Cucumber didn't exist).

So Dan started writing a scenario-running framework on top of the unit-"testing" tool, and then ported it to Ruby as RBehave, which then got turned into plain text and became Cucumber. At that point, BDD became a replacement for ATDD (which was normally done back then with incredibly procedural scripts using unit-testing tools).

It doesn't really matter whether you're using JUnit, NUnit, or any other kind of unit-testing framework at a low-level. If you're thinking in terms of examples of behaviour, and talking through those examples, then you're doing BDD. Writing the examples down is useful, and automating them is useful too, and that's why there are BDD tools like JBehave and Cucumber which work at a system level.

We don't really need specific BDD tools at a lower level, because it's pretty easy for developers and testers to map "test" to "example" or "should" without worrying about it.

The difference is in the ease with which people can have conversations, without using the word "test".

When you're writing BDD for a class, the "user" of that class is usually another class. So, in the same way you write scenarios based on what the user of a system can see, you write lower-level examples based on what another class can see. The tests that come out of BDD are a very nice by-product, but the conversation is the most important aspect, even if that conversation has to happen with a rubber duck.

Answer 2

BDD doesn’t replace TDD, I would argue that it complements BDD.

It all depends on the question, will the business care about this or not?

You want to use the right tool for the job. That is, some stuff fits very well for BDD and some other things fit better with TDD. When done properly, the line between BDD and TDD is very blurred. If it even exists.

I wrote a blog post where I discuss a concept called “Testing Iceberg”, http://www.thinkcode.se/blog/2016/07/25/the-right-tool-for-the-job

It may share some additional light to your question.

And I agree with @Lunivore that the choice of tool is less important compared with the understanding of the problem that you get from conversations.