What is the Difference Between TDD and BDD?

Have you ever had someone ask you a question, and in the process of answering the question, you weren't really sure if you were giving the correct answer?

This happened yesterday where I am working as a contract Sr. QA Engineer.

Question: "What is the Difference Between BDD and TDD? Is it the same thing?"

The answer I gave: No.

Why?

BDD: Behavior Driven Development
TDD: Test Driven Development

BDD is a way a business analyst and a QA Engineer can fashion the requirements and the tests.
TDD is a way of software development. Fashion the unit test first, then the code that supports the test.

BDD is using the Given / Then / When format Dan North came up with when working with TDD (Article, Better Software, Introducing BDD, March 2006), that Martin Fowler then echoed (Blog, GivenTHenWhen, Aug. 2013), that the Cucumber people with their Gherkin-style language ran away with.

That was the answer I gave... How could I have made my answer simpler?

- - -

Here is more information that I found while I was doing research:

Why is the famous BDD tool called Cucumber? Aslak Hellesøy didn't want to pick a geeky name. Read what he said on Quora about why he picked that name. 


BDD style had a direct link from Dan North to Aslak Hellsoy, when Dan donated his rbehave for Ruby to the RSpec project and the RSpec Story Runner that Aslak Hellsoy came across. Aslak liked it, wanted to improve it.

TDD, using Java, for example, you would first write a bit of code in the src/test/java branch, then the src/main/java branch, then back to the src/test/java branch as code was being developed. Write the first unit test, run it, and of course it will fail. RED. Write the code to support the test. Everything passes? GREEN. Need to combine like elements, similar elements in the code? REFACTOR.

TDD had been around for a while before BDD. See Kent Beck's Test Driven Development: By Example (2002) or this Wikipedia article on https://en.wikipedia.org/wiki/Test-driven_development

So how did BDD come from TDD? Dan North < https://dannorth.net/ > in his article Introducing BDD writes:

"While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.
"The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.
"My response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery. Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing".

Happy Testing!

Learning Serenity BDD

• Part One: Serenity BDD: An Automation Framework That Uses Specification by Example (SBE)
• Part Two: What is the Difference Between TDD and BDD?
• Part Three: Studying BDD using The Cucumber Book and BDD in Action
• Part Four: Scaffolding a new project using Maven Archetypes
• Part Five: Reviewing The Serenity Screenplay Tutorial

-T.J. Maher
Twitter | LinkedIn | GitHub

// Sr. QA Engineer, Software Engineer in Test, Software Tester since 1996.
// Contributing Writer for TechBeacon.
// "Looking to move away from manual QA? Follow Adventures in Automation on Facebook!"