# TDD & BDD, No-Nonsense

You've heard the acronyms in code reviews and job postings. Maybe someone on your team insists every line
must be written test-first, and you've quietly wondered whether they're right or just devout. Maybe you
tried TDD once, it felt slow and awkward, and you assumed you were doing it wrong.

Here's the truth almost nobody says out loud: TDD and BDD are *techniques*, not virtues. They solve
specific problems extremely well and add pure overhead everywhere else. This guide explains what each one
actually is, walks a real cycle of both, and then - the part most write-ups skip - tells you plainly when
to reach for them and when to leave them on the shelf.

## How to read this

- **Want the bottom line on whether to use them?** Jump to [Phase 3: Straight Talk - When They Help, When They Don't](03-when-they-help.md).
- **Want it to finally make sense?** Read in order - Phase 1 builds the TDD mental model, Phase 2 adds BDD on top, and Phase 3 gives you the judgment to use both well.

## The phases

1. **[TDD: Red, Green, Refactor](01-red-green-refactor.md)** - test-driven development as a *design* tool, not just verification. The three-step loop, walked through one small worked cycle.
2. **[BDD: Describing Behavior](02-describing-behavior.md)** - behavior-driven development: framing tests as readable behavior in Given/When/Then, and how it sits as a collaboration layer on top of TDD.
3. **[Straight Talk: When They Help, When They Don't](03-when-they-help.md)** - the judgment call. Where TDD shines, where it fights you, when BDD pays for itself, and the trap of performing the ritual without the benefit.

> This guide is the *why and when*. For the hands-on mechanics of writing your first test, see
> [Your First Unit Test](/guides/your-first-unit-test); for where these tests fit in the bigger picture,
> see [Unit, Integration & E2E](/guides/unit-integration-e2e).