What are the primary differences between TDD and BDD?

Test Driven Development has been the rage in the .NET community for the last few years. Recently, I have heard grumblings in the ALT.NET community about BDD. What is it? What makes it different from TDD?

From stackoverflow NotMyself

• Behaviour Driven Development seems to focus more on the interaction and communication between Developers and also between Developers and testers.

  The Wikipedia Article has an explanation:

  http://en.wikipedia.org/wiki/Behavior_Driven_Development

  Not practicing BDD myself though.

  From Michael Stum

• It seems to me that BDD is a broader scope. It almost implies TDD is used, that BDD is the encompasing methodology that gathers the information and requirements for using, amongh other things, TDD practices to ensure rapid feedback.

  From palehorse

• I understand BDD to be more about specification than testing. It is linked to Domain Driven Design (don't you love these *DD acronyms?).

  It is linked with a certain way to write user stories, including high-level tests. An example by Tom ten Thij:

  Story: User logging in
    As a user
    I want to login with my details
    So that I can get access to the site
  
  Scenario: User uses wrong password
  
    Given a username 'jdoe'
    And a password 'letmein'
  
    When the user logs in with username and password
  
    Then the login form should be shown again
  

  (In his article, Tom goes on to directly execute this test specification in Ruby.)

  The pope of BDD is Dan North. You'll find a great introduction in his Introducing BDD article.

  You will find a comparison of BDD and TDD in this video. Also an opinion about DBB as "TDD done right" by Jeremy D. Miller

  From Christian Lescuyer

• I have experimented a little with the BDD approach and my premature conclusion is that BDD is well suited to use case implementation, but not on the underlying details. TDD still rock on that level.

  BDD is also used as a communication tool. The goal is to write executable specifications which can be understood by the domain experts.

  From Thomas Eyde

• To me primary difference between BDD and TDD is focus and wording. And words are important for communicating your intent.

  TDD directs focus on testing. And since in "old waterfall world" tests come after implementation, then this mindset leads to wrong understanding and behaviour.

  BDD directs focus on behaviour and specification, and so waterfall minds are distracted. So BDD is more easily understood as design practice and not as testing practice.

  From Juha Pohjalainen

• There seem to be two types of BDD.

  The first is the original style that Dan North discusses and which caused the creation of the xBehave style frameworks. To me this style is primarily applicable for acceptance testing or specifications against domain objects.

  The second style is what Dave Astels popularised and which, to me, is a new form of TDD which has some serious benefits. It focuses on behavior rather than testing and also small test classes, trying to get to the point where you basically have one line per specification (test) method. This style suits all levels of testing and can be done using any existing unit testing framework though newer frameworks (xSpec style) help focus one the behavior rather than testing.

  There is also a BDD group which you might find useful:

  http://groups.google.com/group/behaviordrivendevelopment/

  From $pageUsers[$post.author].name

• with my latest knowledge in BDD when compared to TDD, BDD focuses on specifying what will happen next. where as TDD focuses on setting up a set of conditions and then looking at the output.

  Thank You, Uma.

  From $pageUsers[$post.author].name

• BDD is largely TDD done right. However, there's additional value that BDD offers. Here's a link on that:

  http://neelnarayan.blogspot.com/2010/07/bdd-is-more-than-tdd-done-right.html

  Neel

  From Neel