Should BDD be automated with unit tests, integration tests, or both?

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 tes开发者_运维问答t 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?

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

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.

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.

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.