# Skill: Apply TDD red-green-refactor cycle to prevent regression bugs

> Lets an AI coding agent write tests before implementation code, prove tests fail (red), then write the minimum code to make them pass (green), and finally refactor -- applies to every new feature or bug fix where silent regression is a risk.

Source: sodigi·learn -- vibecoding/testy-prostymi-slovami · https://sodigi.io/learn/vibecoding/testy-prostymi-slovami

## When to use
- User asks to add a feature to an existing codebase.
- User asks to fix a bug (to prevent it returning silently).
- User asks the agent to "work in TDD mode."
- Anytime a new change could silently affect pre-existing behavior (e.g., adding a promo code to a cart).

## Core rules
- Write the test **before** the implementation code. A test that was never red is not insurance; it is wishful thinking.
- After writing a test, run it and confirm it **fails** for the right reason. Only then write code.
- Write **exactly the minimum code** to turn the failing test green. No extra logic.
- After going green, refactor -- clean names, remove duplication -- while keeping tests green throughout.
- Every new feature must also check that **old behavior still works**. The main value of tests is catching what the new change broke silently.
- Tests check **what the user sees**, not code internals: "cart shows total $99," not "variable subtotal === 99."
- Tests must be **independent**: each one sets up its own data and does not rely on another test's side effects.
- Always test bad paths too: empty input, missing data, server error, edge-case numbers -- not only the happy path.
- Latch onto meaningful, stable identifiers (button text, aria-label, semantic role) -- not fragile CSS class names.

## Procedure
1. Ask the user to describe the desired behavior as a user journey: "As a [who], I want [what] so that [why]."
2. Translate the journey into a failing test. Name it descriptively: `"returns empty array when no items match query"`.
3. Run the test -- confirm it **fails** (red). If it passes without any implementation, the test is broken.
4. Write the minimum implementation to make the test pass.
5. Run the test again -- confirm it **passes** (green).
6. Run all existing tests to confirm nothing regressed.
7. Refactor for readability; keep running the suite after each change.
8. Repeat for the next behavior, including edge cases and error paths.

## Ready-to-use prompt
```
Add [describe the feature] to the project. Work strictly in TDD mode:

1. First describe in plain English what should happen: what the user enters
   and what they should see. One sentence per behavior.
2. Write the tests BEFORE the code. Also write a test that checks the
   existing behavior has not broken -- regression check.
3. Run the tests and show me that the new tests fail (red stage).
   That is expected and required.
4. Now write the minimum code to make all tests pass (green stage).
5. Run all tests again and show that everything is green.
6. Check edge cases: empty input, invalid input, error from the server.
```

## Pitfalls
- Asking for code without specifying TDD mode -- the agent defaults to writing implementation first and may skip tests entirely.
- Trusting a test that was never red -- if it never failed, it may not be testing anything at all.
- Testing only the new feature and ignoring the existing behavior -- the most valuable regression catch is skipped.
- Testing only the happy path -- real-world data is often empty, malformed, or at the boundary.
- Latching tests onto CSS class names -- any style change breaks the tests even when behavior is correct.
- Deleting or disabling a test when it becomes inconvenient -- a failing test is a robot saving your project; fix the code, not the test.