Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

What is the relation of BDD and TDD?

From what I understood BDD adds two main things over TDD: tests naming (ensure/should) and acceptance tests. Should I follow TDD during development by BDD? If yes, should my TDD unit tests be named in the same ensure/should style?

share|improve this question

2 Answers 2

up vote 14 down vote accepted

BDD adds a cycle around the TDD cycle.

So you start with a behaviour and let that drive your tests, then let the tests drive the development. Ideally, BDD is driven by some kind of acceptance test, but that's not 100% necessary. As long as you have the expected behaviour defined, you're ok.

So, let's say that you're writing a Login Page.

Start with the happy path:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

This Given-And-When-And-Then-And syntax is common in behaviour-driven development. One of the advantages of it is that it can be read (and, with training, written) by non-developers -- that is, your stakeholders can view the list of behaviours you have defined for successful completion of a task and see if it matches their expectations long before you release an incomplete product.

There is a scripting language, known as Gherkin, which looks a lot like the above and allows you to write test code behind the clauses in these behaviours. You should look for a Gherkin-based translator for your usual development framework. That's out of the scope of this answer.

Anyway, back to the behaviour. Your current application doesn't do this yet (if it does then why is someone requesting a change?), so you're failing this test, whether you're using a test runner or simply testing manually.

So now it's time to switch to the TDD cycle to provide that functionality.

Whether you're writing BDD or not, your tests should be named to a common syntax. One of the most common is the "should" syntax you described.

Write a test: ShouldAcceptValidDetails. Go through the Red-Green-Refactor cycle until you're happy with it. Do we now pass the behaviour test? If not, write another test: ShouldRedirectToUserDefaultPage. Red-Green-Refactor til you're happy. Wash, rinse, repeat until you fulfil the criteria set out in the behaviour.

And then we move on to the next behaviour.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Now you shouldn't have preempted this to pass your earlier behaviour. You should fail this test at this point. So drop back down to your TDD cycle.

And so on until you have your page.

Highly recommend The Rspec Book for learning more about BDD and TDD, even if you're not a Ruby developer.

share|improve this answer

What is the relation of BDD and TDD?

They are the same thing.

From what I understood BDD adds two main things over TDD: tests naming (ensure/should)

That's not really something BDD "adds". It's just a different convention that is meant to make it easier to teach and understand TDD.

The people who created BDD were all teaching TDD, and they noticed that the hardest thing to understand was that TDD has absolutely nothing to do with testing. Once students got over that hurdle, it went much easier for them. But, it's very hard to divorce yourself from thinking about testing, when the word "test" (or related terminology such as "assert") appears practically everywhere. So, they switched some words around.

But it's only the words! There is no actual difference between TDD and BDD.

and acceptance tests.

Acceptance tests are just as important a part of TDD as they are of BDD. Again: there is no difference between TDD and BDD: TDD done right is BDD, BDD is TDD done right.

share|improve this answer
In what way are acceptance tests an important part of TDD? –  Idsa Oct 1 '11 at 14:46
@Idsa: they're important in that your code should not pass the tests that you think they need to pass, but the ones that the code is supposed to do. I think too many people get confused by this, that most unit tests are low-level and thus avoid the difficult problem of testing what the system was written to do overall. –  gbjbaanb Oct 1 '11 at 14:55
@Idsa: In the same way that they are important for BDD, of course, since the two are the same thing! The acceptance tests drive the outer cycle of TDD, the one dealing with features and users, as opposed to the more detailed inner cycle which deals with APIs and protocols and such. I think Kent Beck calls this "Zoom In / Zoom Out". You can, for example, easily see this in the JUnit test suite, which contains probably at least as many acceptance tests as it contains unit tests. –  Jörg W Mittag Oct 1 '11 at 15:03
Acceptance tests are an important part of TDD and BDD. But to say that BDD equals TDD is akin to saying TDD equals test-first. Unless you're allowing the tests to drive your code, you are not doing TDD (I used to know someone who was happy to write tests up front but argued that code should always be written as it would be if you weren't writing unit tests and that tests should be written accordingly). Likewise, unless you're allowing the behaviour to drive your tests, you are not doing BDD. –  pdr Oct 1 '11 at 16:25
@Idsa: Note that there are many wrong descriptions of TDD, which don't include acceptance tests. Those -- unfortunately pretty popular and pretty widely taught -- wrong descriptions are one of the reasons why the BDD people thought it might be a good idea to rebrand TDD under a different name, to avoid the confusion. Nevertheless, and it cannot be repeated often enough, TDD and BDD are exactly the same thing. –  Jörg W Mittag Oct 1 '11 at 20:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.