These are the three acronyms that cause the most confusion, which is exactly why they show up all the time in a QA's routine. All three share the same core idea: write the test before the code. The difference lies in who writes it, at what level, and to what end. Understanding that split is what separates repeating the acronym from knowing how to apply it.

The mental map

Before the details, a view from above. The three techniques live in different layers of the same flow:

            "Are we building the right thing?"   (business)
                                 │
        ┌────────────────────────┴────────────────────────┐
        │                                                  │
       BDD ──────────────► ATDD ──────────────►          TDD
  behavior from the        acceptance criterion      unit of code
  user/business            becomes an executable     becomes a technical
  point of view            acceptance test           test (red-green-refactor)
        │                          │                        │
   ubiquitous language       "three amigos"            developer alone
   (Gherkin)                 PO + Dev + QA             in the editor, in seconds
        │                          │                        │
        └──────────► focus on the "what" ◄──────┐    focus on the "how"
                                                └── "Are we building
                                                     the thing the right way?"

TDD — Test-Driven Development

This is the most technical and most granular level. The developer writes a failing unit test, does the minimum to make it pass, and refactors: the red-green-refactor cycle. The target is the internal design of the code: classes, functions, isolated business rules.

// Red — the test fails because the rule does not exist yet
test('applies 10% discount above $100', () => {
  expect(calcularTotal(150)).toBe(135);
});

// Green — the minimum to make it pass
function calcularTotal(valor) {
  return valor > 100 ? valor * 0.9 : valor;
}

// Refactor — now with the green safety net

TDD is not about coverage; it is about design driven by usage. The important detail for QA: a TDD test speaks the language of the code (calcularTotal, toBe(135)), not the user's.

ATDD — Acceptance-Test-Driven Development

One level up. Before coding, the team turns the story's acceptance criterion into a concrete acceptance test. The key piece is the conversation known as the "three amigos" (Product Owner, Dev, and QA): together they define, with examples, what "done" means before a single line of code exists.

ATDD prevents the most expensive bug of all: correctly building the wrong feature. The acceptance test is the written agreement of "done".

QA is usually the protagonist here: the one asking "what if the amount is negative?", "and the exact $100 limit, does it get the discount or not?". Those questions become the acceptance tests.

BDD — Behavior-Driven Development

This is the evolution of ATDD with a focus on language. BDD proposes describing the system's behavior from the user's point of view, in a ubiquitous language that business and tech read the same way. In practice, this shows up as Gherkin scenarios (Given / When / Then):

Feature: Cart discount

  Scenario: Purchase above the limit gets a discount
    Given a cart with $150.00
    When the customer checks out
    Then the total charged should be $135.00

This scenario is readable by the business and executable by automation (via Cucumber, Behave, SpecFlow…). This is what is called living documentation: the specification and the test are the same artifact. I covered the syntax in the post on Gherkin and Given-When-Then.

Side by side

How they coexist

The mistake is treating them as competitors. In practice they stack: BDD/ATDD define what to deliver (a few high-level scenarios, near the top of the test pyramid), and TDD ensures that every little piece of code supporting that behavior is born correct (many fast tests, at the base). A mature team uses all three at once, in layers.

Pitfalls that show up day to day

• "BDD is a tool." No. BDD is a collaboration practice. Cucumber is a tool; writing Gherkin without the three amigos conversation is just new syntax for the same old silo.
• Gherkin describing clicks. "Given I click the blue button" ties the scenario to the screen. Behavior is what happens, not how you navigate.
• Confusing ATDD with "QA writes the test afterwards". The "driven" is literal: the test comes first and guides development.
• TDD turning into dogma. It shines on business rules; for a throwaway prototype, it may be overkill. Use the right tool for the context.

Conclusion

TDD takes care of the code, ATDD takes care of the agreement, BDD takes care of the conversation, and all three take care of testing first. Knowing which layer each one operates in is what lets you choose the right technique for the problem in front of you, instead of applying all of them by reflex.