Test-First: TDD & BDD

Most people assume you write code first and test it afterward. But some teams flip that around and write the test before the code. Two named practices do this: Test-Driven Development (TDD), with its tight repeating loop, and Behavior-Driven Development (BDD), which writes tests as plain-language scenarios. Both make the requirement concrete before any code exists.

It sounds backwards at first — how do you test code you haven't written? — but writing the test first forces you to decide exactly what "working" means before you start, which turns out to be a powerful discipline.

An analogy: writing the answer key before the exam. If you know exactly what a correct answer looks like up front, every question has a clear, gradeable target — and you can't fool yourself about whether you got there.

TDD: The Red-Green-Refactor Loop

Test-Driven Development follows a tight three-step loop, repeated over and over. Red: write a small test for behavior that doesn't exist yet — it fails (red). Green: write the simplest code that makes the test pass (green). Refactor: clean up that code now that it's protected by the passing test. Then repeat for the next small piece. The code grows in tiny, always-tested steps.

Why Test-First

Writing the test first has two big payoffs. It forces you to clarify the requirement before coding — you can't write the test without deciding exactly what the code should do. And it pushes you toward testable design, because code that's hard to test is usually a sign of code that's tangled. The test isn't an afterthought checking your work; it's a specification you write down first and then satisfy.

BDD: Behavior in Plain Language

Behavior-Driven Development takes the test-first idea and writes the tests in near-English scenarios that non-developers can read, usually in a "Given / When / Then" form: Given a user with a habit, When they check it off, Then the streak goes up by one. This lets product people, testers, and developers agree on behavior in the same words. BDD is as much a collaboration practice as a testing one — it gets everyone describing behavior the same way.

Not All-or-Nothing

You don't have to adopt these purely. Many teams use strict TDD for the tricky, high-risk parts and write tests after the fact for the simpler ones. Doing some test-first work where it helps most is far better than an all-or-nothing stance. The goal isn't ideological purity; it's clear requirements and well-tested code, by whatever mix gets you there.

On Cadence, the rule "a streak resets after a missed day" is fiddly and easy to get wrong, so Marcus writes the failing test first: set up a habit, skip a day, assert the streak is back to zero. Then he writes just enough code to make it pass, and cleans it up. He knows exactly when he's done — the test goes green — and that test now documents the rule forever, for whoever touches it next.