Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 and testers.

share|improve this question
1  
That's one crucial difference, yes. –  Alex Feinman Feb 15 '12 at 17:50
13  
BDD = Behavior Driven Development, for anyone else wondering. TDD = Test Driven Development, for completeness. –  MackieChan Apr 15 '13 at 23:45

6 Answers 6

up vote 102 down vote accepted

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.

share|improve this answer
56  
Exactly. There is no difference between BDD and TDD. BDD is TDD done right. TDD done right is BDD. The problem is that doing TDD right is hard, or more precisely learning how to do TDD right is hard. The reason is that TDD has absolutely nothing whatsoever to do with testing, but it is hard to understand that important fact when all the terminology is about testing. So, BDD literally is just TDD with all the testing terminology replaced with behavioral examples terminology. It's like that "try not to think of a pink elephant" thing. –  Jörg W Mittag Feb 16 '12 at 3:40
3  
I love the "Try not to think of a pink elephant" example because once you tell someone to do that, that's all they can think of LOL. –  Mike Brown Feb 28 '13 at 16:13
7  
Agreed. The trouble with TDD/BDD/xDD is that whichever one you come at first makes other approaches seem a little strange, the key point is not to worry about it too much and use whichever approach fits your circumstances best. A very common approach is to use BDD type approaches for the BA's to define your requirements (Given/When/Then in your stories) but the devs themselves don't use a BDD framework. They just convert the reqs. to TDD type approaches as they code and write unit/integration/acceptance tests in a standard xUnit type framework. –  Chris Lee Jan 15 at 22:32
2  
+1 blew my mind –  MasterMastic Feb 3 at 15:47

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.

share|improve this answer
    
How about larger and complicated projects. Is better to split up the BDD and TDD aspects into their own projects and test seperately? –  arjun Feb 15 '12 at 17:26
    
The behavior itself can be broken into granular test cases and tested in BDD. I am confused when people talk about splitting BDD and TDD aspects –  arjun Feb 15 '12 at 17:32
3  
You're right--the unit tests still test the behavior of the method. I think the confusion is probably because it may be difficult to trace the behavior of the method directly to the behavior that the external stakeholders asked for and/or understand. –  Matthew Flynn Feb 15 '12 at 17:36
    
As for splitting the two into different projects--it would depend on whether the presence of the "techie" unit tests would confuse the folks who need to review the tests for the "behavior" mapped to the requirements. If it's useful to separate them, go ahead. Otherwise, I wouldn't bother. –  Matthew Flynn Feb 15 '12 at 17:41
    
@MatthewFlynn traceability between behaviour and the code is definitely the issue, to do that you need to understand the design (not something the stakeholder may be capable of) –  jk. Feb 15 '12 at 19:08

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.

share|improve this answer

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.

share|improve this answer

In my experience the biggest problem with TDD is the "T". It causes the lay-person (managers, testers, non-TDD devs) to equate it in their minds with the traditional post-development "Testing" phase of a waterfall style. That is something that anyone can get their head around.

The problem that many struggle with is that TDD is for developers, not testers. Done right TDD is not primarily a test strategy or an acceptance test tool, but a technique that drives good software design from the ground up - small, loosely coupled classes, clear, well defined interfaces, and continually cleaned code through on-going refactoring. Refactoring that is performed routinely, frequently, and from a position of confidence.

That you happen to end up with a comprehensive test suite that can form part of your CI / build process is a bonus, not the goal.

BDD compliments this by bridging the gap between business requirements and higher-level acceptance tests. It is the satisfying of the BDD suite that scopes out the development process and which determines when the product as a whole has been adequately delivered.

share|improve this answer

Since my last reply wasn't very successful, I will try a very straightforward approach.

  • Behaviour Driven Development is a subset of Test Driven Development
  • TDD focuses on each and every unit test for every function, doesn't matter what it does. BDD focuses on software that matters
  • Idiom. TDD settles for tests, BDD enforces story telling format

JavaScript Examples

Unit tests in jasmine (BDD)

describe("A suite", function() {
  it("contains spec with an expectation", function() {
    expect(true).toBe(true);
  });
});

Unit tests in jsUnity (TDD)

function test_lists() { assert.areEqual([1, 2, 3], [1, 2, 3]) }

Here are some Python libraries that help create more BDD like tests with unittest frameworks:

  • Lettuce: Cucumber for python
  • HamCrest
share|improve this answer

protected by gnat Apr 7 at 6:43

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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