TDD and BDD Differences

Question

I honestly don't see the difference between BDD and TDD. I mean, both are just tests if what is expected happens. I've seen BDD Tests that are so fleshed out they practically count as TDD tests, and I've seen TDD tests that are so vague that they black box a lot of code. Let's just say I'm pretty convinced that having both is better.

Here's a fun question though. Where do I start? Do I start out with high level BDD tests? Do I start out with low level TDD tests?

Eggett

See also What are the primary differences between TDD and BDD? – Unmoral

Possible duplicate of What are the primary differences between TDD and BDD? – Consonance

Answer 1

I honestly don't see the difference between BDD and TDD.

That's because there isn't any.

I mean, both are just tests if what is expected happens.

That's wrong. BDD and TDD have absolutely nothing whatsoever to do with testing. None. Nada. Zilch. Zip. Nix. Not in the slightest.

Unfortunately, TDD has the word "test" in pretty much everything (not only in its name, but also in test framework, unit test, TestCase (the class you tpyically inherit from), FooTest (the class which typically holds your tests), testBar (the typical naming pattern for a test method), plus a lot test-related terminology such as "assertion" and "verification") which leads some people to believe that it actually does have something to do with tests. So, some smart people said: "Hey, let's just change the name" to remove any potential for confusion.

And that's what BDD is. It's just TDD with any test-related terminology replaced by examples-of-behavior-related terminology:

• Test → Example
• Assertion → Expectation
• assert → should
• Unit → Behavior
• Verification → Specification
• … and so on

BDD is just TDD with different words. If you do TDD right, you are doing BDD. The difference is that – provided you believe at least in the weak form of the Sapir-Whorf Hypothesis – the different words make it easier to do it right.

Jann

Thanks @Jörg. The language is one of the most fundamental concepts in BDD. The only thing missing is the focus on conversations and discovery, before the "test" is even written. I would say that there is a difference; the language and the questions the language evoke make the difference, and it's profoundly, subtly important. – Parrie

Offtopic: i totally agree with the "The language is one of the most fundamental concepts in BDD" but i donot like the term "behavior". I prefer "Benefit driven development" and putting the benefit first "In order to {benift} as a {rolemeber} i want {feature}. – Paludal

@Paludal - that template is from Chris Matts Feature Injection, which evokes BDD's questioning / model-breaking patterns in the analysis space. Chris was involved in the formation of BDD but hadn't come up with the template when Dan North came up with the name (and he agrees that Feature Injection is also an awful name). The tag's always been "writing software that matters" though. – Parrie

Can you share your sources that defines that TDD has nothing to do with tests? I'm very confused as, from Software Engineer (Sommerville), this is what I've learned: Test-driven development (TDD) is an approach to program development in which you interleave **testing** and code development (Beck, 2002). Essentially, you develop the code incrementally, along with a **test** for that increment. You don’t move on to the next increment until the code that you have developed **passes its test**. Test-driven development was introduced as part of agile methods such as Extreme Programming. – Liliuokalani

Confusing BDD with TDD is like confusing Macroeconomics with Microeconomics. They are different. BDD = building an understanding of requirements using examples and optionally may be used to drive automated Macro tests. (agilenoir.biz/en/am-i-behavioral-or-not), TDD = writing micro tests to drive writing coding. The Agile Thoughts podcast covers these differences too: agilenoir.biz/en/agilethoughts/test-automation-pyramid-series – Briar

downvote the answer because the "That's because there isn't any." is absolutely wrong. There are many references which explain the differences as cucumber.io/blog/bdd/bdd-vs-tdd for example – Factorial

downvote as the answer is wrong. There is a difference between BDD and TDD. BDD is more a collaboration process and the result of it is to derive the scenarios which are used by the Devs and QAs to implement and test the solution. TDD is purely for devs to write better code. Here is my blog explaining the differences between BDD and TDD blog.nocodebdd.com/bdd-vs-tdd – Strawn

Answer 2

BDD is from customers point of view and focuses on excpected behavior of the whole system.

TDD is from developpers point of view and focuses on the implementation of one unit/class/feature. It benefits among others from better architecture (Design for testability, less coupling between modules).

From technical point of view (how to write the "test") they are similar.

I would (from an agile point of view) start with one bdd-userstory and implement it using TDD.

Paludal

Well... BDD actually started out at the TDD level. Here you go: blog.dannorth.net/introducing-bdd - should help. – Parrie

Updated link from above comment dannorth.net/introducing-bdd – Ingenious

Answer 3

From what I've gathered on Wikipedia, BDD includes acceptance and QA test that can't be done without stakeholders/user input. Also BDD uses a natural language to specify its test while TDD usually uses programming language. There might be some overlap between the two but I think it's not the vagueness but BDD's language that is the main difference.

As for where you are to start, well that really depends on your development process, doesn't it? I assume if you are doing bottom-up that you're going to write TDD first and once you reach higher level you'll use BDD to test if those features work as expected.

As k3b noted: main difference would be that BDD is problem-domain oriented while TDD is more oriented solution-domain.

Casuistry

Your comment is very sensible given what users are generally fed about BDD and TDD and certainly in the context of "popular tools" (e.g. languages and their dev/delivery systems). What really helped me "get" BDD was when I saw that it was really Hoare-logic, which is the basis for Design-by-Contract. Once I saw that, I quickly realized that BDD has a pure-code version that can be applied to any code module at any level. It can also be applied at a human-level for human-level testing (e.g. QA/QC, Biz-analysis, alpha-testing, beta-testing, and even User Doc writing, etc.). – Quintinquintina

Answer 4

Just copying the answer from Matthew Flynn which I agree more than "TDD and BDD have nothing to do with tests":

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.

Liliuokalani

This helps to highlight how BDD understanding is generally skewed and incomplete. BDD and TDD are both about Software Correctness—at both the User/System Requirements API level and in the deep-dive of software modules supporting it. Just take the notion of "correct" and start asking: Is my class-state correct before and after calls and accesses to its methods, functions, and properties? Is the state of my class and arguments correct when this method or function is called? Is the state of this class-property correct at all times? The entire thing is about software correctness. Period. – Quintinquintina

Eiffel and EiffelStudio have this notion of properly applied software correctness tools baked into the language specification, compiler, static-analysis tools, and testing tools. They are all thoughtfully designed to work together as a complementary set of tools to give you what you need to ensure your software is as correct as it can be at any level—both at the User/System requirements level and all the way down to the deepest library code level. – Quintinquintina

Answer 5

BDD is about getting your TDD right. It provides "structure and diciplene" to your TDD. It guides you in testing the right thing and doing the right amount of test. Here is a fantastic small post on BDD and TDD,

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Crutchfield

First, the writer is not a native English speaker, so one needs to have a caution to read this tongue-in-cheek as one scrambles over the bad-grammar speed bumps. Second, notions like—"Test-driven Development is hardly about testing"—is questionable at best and laughable at worst. Of course TDD is about testing. No one in the TDD paradigm actually thinks, expects, or believes that TDD code assertions replace a human being testing the code—certainly not in alpha, beta, or other pre-production testing. TDD never stood on that hill and planted a flag. – Quintinquintina

Answer 6

I think the biggest contribution of BDD over TDD or any other approaches, is making non-technical people(product owners/customers) part of the software development process at all levels.

Writing executable scenarios in natural languages have almost bridged the gap between the requirement and the delivery.

Product owners can himself run the scenarios he had written and test with different data sets if he wants to play around the behavior of the code written by the development team.

That's amazing! Customer is sitting right at the center and precisely not just asking what he really wants but verifying and experiencing the deliverables as well.

Acumen

You are substantially correct to point out that there is an API level where users have a Given-When-Then (i.e. BDD) interaction as a Client of a software system. In this case, BDD is precisely as you say—a definition of preconditions and post-conditions from the Client-User point of view. What people fail to see is how BDD as Design-by-Contract goes beyond skin-deep of the Client-User API and is applicable to every class, method, property, and function of a software system. See my comment below for more and an example on Github. – Quintinquintina

Answer 7

A fantastic article on the differences between TDD and BDD:

http://www.lostechies.com/blogs/sean_chambers/archive/2008/12/07/starting-with-bdd-vs-starting-with-tdd.aspx

Should give you everything you need to know, including problems with both, and examples.

Schmooze

Answer 8

Terminology are different, but in my work, i use TDD to dev detail, mainly for unit test, and the BDD is more high level, for customer, QA or no-tech man .

Antemeridian

Docs on TDD/BDD are realy open to interpretation. Here is mine: https://mcmap.net/q/129558/-tdd-how/45971814#45971814 – Rayburn

Answer 9

Overall

BDD is really Design-by-Contract using different terms. Generally speaking, BDD is in the form of Given-When-Then, which is roughly analogous to Preconditions (Given), Check-conditions/Loop-invariants (When), and Post-conditions/Invariants (Then).

Notice

Note that BDD is very much Hoare-logic (i.e. {P}C{Q} or {P}recondition-[C]ommand-{Q}Post-condition). Therefore:

• Preconditions (Given) must hold true for the command (method/function) to compute correctly. Any violation of the Given (precondition) signals a fault in the calling Client code.
• Command(s) (When) are what happens after the precondition(s) are met. In Eiffel, they can be punctuated within the method or function code with other contracts. Think about these as though they are QA/QC checks along a process assembly line.
• Post-conditions (Then) must hold true once the Command (When) is finished.

Moral of the Story

Because BDD is just DbC (Hoare-logic) repackaged in different words, this means it is not TDD. Why? Because TDD is not about preconditions/checks/post-condition contracts tied directly to methods, functions, properties, and class-state. TDD is the next step up the ladder in testing methods, functions, properties, and classes with their discrete states. Once you see this and fully appreciate that TDD is not BDD and BDD is not TDD, but that they are separate and complementary technologies for software correctness proofs—THEN—you will finally understand these topics correctly. You will also use and apply them correctly.

Conclusion

Eiffel is the only language I am aware of where BDD (Design-by-Contract) is baked raw into both the language specification and compiler. It is not a Frankenstein bolt-on monster with limitations. In Eiffel, BDD (aka DbC) is an elegant, helpful, useful, and direct participant in the software correctness toolbox.

See Also

Wikipedia helps defined Hoare-logic. See: https://en.wikipedia.org/wiki/Hoare_logic

I have created an example in Eiffel that you can look at. See:

Primary class: https://github.com/ljr1981/stack_overflow_answers/blob/main/src/so_73347395/so_73347395.e

Test class: https://github.com/ljr1981/stack_overflow_answers/blob/main/testing/so_73347395/so_73347395_test_set.e

Quintinquintina

Answer 10

The main difference is just the wording. BDD uses a more verbose style so that it can be read almost like a sentence.

Wriest

Verbosity is not the main difference. BDD and TDD are not the same thing, nor are they trying to be. TDD wants to test objects from the outside—that is—using the object's (or modules) API. On the other hand, BDD is trying to pretend to be Design-by-Contract and test from the inside. The problem with BDD is that it is implemented from the outside like TDD, which is why BDD fails to cross the finish line of Hoare-logic. See my comment below on TDD vs BDD, Hoare-logic, and Design-by-Contract. – Quintinquintina