Take the 2-minute tour ×

BDD has been touted as "TDD done right".

However TDD is widely used with unit tests, rather than end-to-end integration tests.

Which kind of test is most appropriate for BDD?

  • Should we write only integration tests?
  • Should we also write unit tests?
    • If yes, should there be multiple unit-tests per scenario?
    • And what a unit test covers multiple scenarios? Is there a way to structure these tests when using a testing framework such as MSpec?
share|improve this question
No, Yes, What?, I don't know. –  Ritch Melton May 11 '11 at 0:20

4 Answers 4

up vote 10 down vote accepted

Which kind of test (integration tests, unit tests) is most appropriate for BDD?

I would use both in two nested loops as described in Behavior-Driven Development with SpecFlow and WatiN

* writing a failing integration tests
    * writing a failing unit test as part of the solution of the integration test
        * making the unittest pass
        * refactor
    * writing the next failing unit test as part of the integration test

    * unitl the integration test passes

* writing the next failing integration tests
share|improve this answer

The reason you often see acceptance/integration tests used in the BDD cycle is because many of it's practitioners put a heavy emphasis on mocking and outside-in development. As such they tend need to include both end-to-end integration/acceptance tests as well as unit tests to ensure the total behavior of the system.

When fake objects are being used as collaborators instead of real objects in a unit test, it is quite easy to verify that the isolated unit under test behaves in the proper fashion (that is that it modifies it's state properly, and sends the proper messages). However it can not verify anything more than that in isolation the individual object behaves as expected. As such, an end-to-end acceptance test is then necessary verify that all the objects in the system when used together provide the promised value to the end user.

So basically within this approach unit tests and acceptance tests play the following roles:

Unit Tests - Objects in isolation behave in the proper manner

Acceptance/Integration Tests - All Objects together provide the promised value of the system.

Although I myself am a large proponent of this style of development, it is somewhat independent from the general BDD ideas. In my opinion acceptance/integration tests are only necessary when your isolating your system under test in your unit tests by using mocks and stubs.

share|improve this answer
+1 (ok perhaps that's a bit redundant if you also upticked the answer, I guess I wanted 'credit' for my upvote ;-) –  Chuck van der Linden May 11 '11 at 19:33
And one year later, here it is! –  Clemens Helm May 27 '13 at 14:19

I'll give the answer that seems most likely to me, but I might be off-track here.

TDD was originally implemented with unit-tests, which clarify requirements for individual components of the software by calling them and expecting certain results.

BDD simply applies the same concept to the system as a whole. So for BDD, you write integration tests, which call the system from the outside-in, by simulating mouse clicks, etc, or whatever interface the end-user uses to access the system.

BDD seems to actually be a kind of black-box/UAT testing, since it's concerned with the behaviour of the system as a whole, not with the means by which the behaviour is implemented.

So it seems advisable to write unit tests and integration tests, but at the very least, integration tests, so that if we don't have time to verify each component, we can at least verify the system as a whole.

share|improve this answer
This isn't quite correct. The BDD approach can be used for both unit tests and integration tests. –  Andy Waite May 11 '11 at 9:12
another aspect of BDD is incorporating the idea of an executable specification, which is something TDD did not do. typically that means you have both unit tests for the actual code modules, and integration tests that make sure when working on combination those units of code actually deliver the value the customer wanted. Even if you are not working in ruby, having a look at The RSpec Book is useful in this regard I think. –  Chuck van der Linden May 11 '11 at 19:31

The basic idea is to write the tests before the code, so for any feature, use the test appropriate to examine the feature. If the feature you are adding is "clicking on the report bug link should send an email", then an integration test seems appropriate (presumably with some unit tests for components of that feature). If the feature you are working on is "Average usage calculation should omit the highest and lowest value", a unit test is probably more appropriate. The important thing is to accurately be able to tell when what you are building is done, and later to be sure changes didn't break it. The rest is just bookkeeping.

share|improve this answer

Your Answer


