What is the difference between BDD and TDD?

Question

I have been learning writing test cases for BDD using specflow. If I write comprehensive tests with BDD is it necessary to write TDD test separately? Is it necessary to write test cases for both TDD and BDD separately?

It seems to me that both are same, the only difference being that BDD can be understood by non developers.

Answer 1

The difference between BDD and TDD is that BDD begins with a B and TDD begins with a T. But seriously, the gotcha with TDD is that too many developers focused on the "How" when writing their unit tests, so they ended up with very brittle tests that did nothing more than confirm that the system does what it does.

BDD provides a new vocabulary and thus focus for writing a unit test. Basically it is a feature driven approach to TDD.

Answer 2

Behavior Driven Development is an extension/revision of Test Driven Development. Its purpose is to help the folks devising the system (i.e., the developers) identify appropriate tests to write -- that is, tests that reflect the behavior desired by the stakeholders. The effect ends up being the same -- develop the test and then develop the code/system that passes the test. The hope in BDD is that the tests are actually useful in showing that the system meets the requirements.

UPDATE

Units of code (individual methods) may be too granular to represent the behavior represented by the behavioral tests, but you should still test them with unit tests to guarantee they function appropriately. If this is what you mean by "TDD" tests, then yes, you still need them.

Answer 3

BDD utilizes something called a "Ubiquitous Language," a body of knowledge that can be understood by both the developer and the customer. This ubiquitous language is used to shape and develop the requirements and testing needed, at the level of the customer's understanding.

Within the confines of the requirements and testing dictated by BDD, you will use "ordinary" TDD to develop the software. The unit tests so created will serve as a test suite for your implementing code, while the BDD tests will function more or less as acceptance tests for the customer.

Answer 4

The differences between TDD and BDD are subtle and mostly boil down to language. BDD tests are often written in the following form:

public void shouldBuyBread() throws Exception {
   //given  
   given(seller.askForBread()).willReturn(new Bread());

   //when
   Goods goods = shop.buyBread();

   //then
   assertThat(goods, containBread());
 }  

If you frame the test in terms of behavior it helps scope the responsibility of the class and leads to better design (at least according to BDD'ers). BDD sometimes focuses on executable specifications that your domain experts/customers can understand.

BDD is also more associated with what Martin Fowler calls 'outside-in' or 'mockist' tests, as opposed to state-based verification.

Answer 5

They are the same thing really. Good unit tests allow flexibility to bravely make changes, without inadvertently breaking the program. The bad unit tests are somewhere between unit tests and functional tests.

functional tests / acceptance tests, are user related. Like.. "if I click on this button, I want something to happen". IMHO these tests, don't have to be very automated. testers pick this stuff up.

unit tests are completely the other way around. You test the smallest chunks of functionality you can. So that changing up the unit cant break any other tests.