test-driven-development

1# Test-Driven Development
2 
3## Overview
4 
5Write a failing test before writing the code that makes it pass. For bug fixes, reproduce the bug with a test before attempting a fix. Tests are proof — "seems right" is not done. A codebase with good tests is an AI agent's superpower; a codebase without tests is a liability.
6 
7## When to Use
8 
9- Implementing any new logic or behavior
10- Fixing any bug (the Prove-It Pattern)
11- Modifying existing functionality
12- Adding edge case handling
13- Any change that could break existing behavior
14 
15**When NOT to use:** Pure configuration changes, documentation updates, or static content changes that have no behavioral impact.
16 
17**Related:** For browser-based changes, combine TDD with runtime verification using Chrome DevTools MCP — see the Browser Testing section below.
18 
19## Discover the Stack First
20 
21The TDD cycle is universal; the commands are not. Before writing the first test, discover how *this* repository tests, and use its commands for every RED, GREEN, and verification step:
22 
23- **Language and build system** — `package.json`, `pom.xml`/`build.gradle`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`, a `Makefile`
24- **Checked-in wrappers** — prefer `./gradlew`, `./mvnw`, `make test`, or a repo script over globally installed tools
25- **Test framework and configuration** — and how it runs a single focused test vs the full suite
26- **Existing conventions** — where tests live, how files are named, what patterns neighboring tests follow
27…