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
BDD is a set of well documented TDDs (Unitests) – D.D Nov 25 at 8:33

3 Answers 3

up vote 17 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

My understanding of it:

  • BDD started as a rebranding of TDD to make the focus on behaviour clearer.
  • It gives more formal support (DSL and tooling) for a focus on behaviour and executable specifications.
  • BDD can now be seen as a superset of TDD,. It has grown over-time to encompass more of the requirements elicitation side of things, but still the development process side is a core part of it.

So to address the TDD done right part of BDD. BDD started as a change in language of TDD to make the intention of the process clear. Dan North's introductory article on BDD explains why focusing on the word behaviour rather than test is useful - it helps confirm that you are not just building the software right, you are also building the right software. This was always part of a good TDD approach, but Dan codified it a bit into BDD.

What I think BDD makes a bit more explicit than TDD, or at least formalises and provides tool support for, is this two-cycle / double loop / zoom-in zoom-out / outside-in approach. You first describe the expected behaviour of the feature (the outside loop), then zoom-in to the inner loop to deal with the low-level specifications.

Doubleloop TDD From

Gherkin in conjunction with tools like Cucumber and SpecFlow provide a way of writing those high-level feature specifications and then linking them in to code that executes the application code. I would argue that this is where BDD might 'feel' different from TDD, but it really still is doing the same thing, just with some added tool support and a DSL. Somewhat closer to 'traditional' TDD is using tools like rspec, nspec, spock. These feel a little more like the same process you'd do in 'traditional' TDD but with more behaviour-focused language.

In BDD in Action by John Ferguson Smart (highly recommended), he advocates for a double loop approach, starting with something like jBehave at the outer level executable specifications, then dropping into a tool like Spock for the low-level specifications.

BDD brings the concept of test-driven closer to the business stakeholders. Gherkin is designed to be business readable, and the idea of 'living documentation', i.e. automatically produced progress reports from your executable specifications is about giving feedback to the stakeholders.

Another part of BDD now, which is where it genuinely becomes something that incorporates TDD as part of a larger process, are the requirements elicitation bits and pieces. Ideas like Feature Injection, Impact Mapping, and Real Options are part of this side.

For the canonical answer on this, it might be best to go to Dan North again. If your team is all developers, then BDD = TDD. If your team involves a whole range of stakeholders, BDD is closer to XP, with TDD being one part of it.

share|improve this answer

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.