Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

I recently made a start on learning BDD (Behaviour Driven Development) after watching a Google tech talk presented by David Astels. He made a very interesting case for using BDD and some of the literature I've read seem to highlight that it's easier to sell BDD to management. Admittedly, I'm a little skeptical about BDD after watching the above video. So, I'm interested to understand if BDD is indeed nothing more than a change in vocabulary or if it offers other benefits.

share|improve this question

marked as duplicate by gnat, MichaelT, Yannis Apr 4 '13 at 20:48

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

up vote 5 down vote accepted

It's more than just a semantic change.

BDD focuses on getting your tests defined with the stakeholders - this doesn't exist in TDD (where a developer defines the tests).

Tests are supposed to be readable by non programmers and are the use cases that the code and the reasons for the code flow from.

I suggest you read both the TDD and BDD wikipedia pages as a comparison between the two.

share|improve this answer
But don't the tests in TDD reflect user stories that come from collaborating with the stakeholders? – Desolate Planet Mar 1 '11 at 22:07
@Desolate Planet - Yes, TDD tests derive from user stories. BDD is about actively working with the stakeholders and writing the tests together, at the same time. – Oded Mar 1 '11 at 22:09
@Desolate Planet - aren't many tests at more of a detailed level than what you would find in a user story? – JeffO Mar 1 '11 at 22:17
I would say that TDD tests may reflect user stories, but they may also reflect vary low behavior of classes (or whatever unit is in your project), which itself is not story. For example class that handles sessions, may have tests that are hard to express from user POV. BDD will reflect user stories, without going into single class behavior. – yoosiba Mar 2 '11 at 0:17
Just as a note, you can also do BDD at a unit level (in fact, this is where it started). We use examples of how a class, or application, should behave, in order to question our assumptions. For applications, it's useful to question those assumptions with other stakeholders, because we're crossing a boundary from the business domain and English to the technical domain and code. The same pattern can also apply at higher levels, questioning a project vision, stakeholder goals, etc - see Feature Injection; BDD in the analysis space. – Lunivore Mar 17 '11 at 10:49

You really need to do both. Here's how I would suggest doing it.

Step 1:

Get stories from management, give them to developers. They use TDD to write low-level, fast executing tests that may mock objects or use fake data to ensure things are making sense to the system they are designing within. Then they actually code the story, and do a sanity check that their expected goals match the output from their work. If not, they either change their tests, or their work, depending on the severity of the error in either the test or the code.

Step 2:

After a few dozen of these stories have been merged into a feature, they are committed to the repository and become something that users might see (in a website, or an api, etc). This is where BDD is different. Once a feature is finished you write a test that outlines the behavior of the feature as a user might describe it to someone else, and exercise the functionality not from within the system, but as much as possible, as a user would exercise your feature. That means if the feature is available over the web, use the web to get to it. If you have to enter it three forms before a new user can see a feature for the first time, fill out the three forms first. TDD will normally pretend that those three forms are already filled out for a certain test, or they may pretend to GET a resource from a server, etc (it keeps the focus of the test small, and the runtime low; two key goals of tests). BDD doesn't care if your firewall breaks a feature in production; the behavior is broken, and that's all a user cares about. So integration between many features, unexpected clashes between scenarios or unexpected outcomes from user activities are fair game for BDD. Everything is important from a high level perspective in BDD.

These tests may take several minutes to run each, and you may have hundreds of them that together take hours to run (as would be the case for smoke tests for a website). They are also written using some frameworks that abstract the plain text descriptions of the behavior that exist in the form of modules that contain code. Those methods might then generate calls to databases, servers, or local system resources to modularize "steps" that occur during these tests. The tricky part here is writing them to effectively stand apart from each other, so that they are useful on their own when used in many different tests (if you have something like logging in, writing a message to people, or some other task that is common between many different features).

share|improve this answer

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