# Red-green-refactor

Concept · [Technical basics](https://ecosystem.samcarlton.com/technical)

Also called: red green refactor, test-driven development, TDD, test first

A way of [writing code](https://ecosystem.samcarlton.com/code) in three steps: write a test that fails (red), write just enough code to make it pass (green), then clean up the code while the test keeps passing ([refactor](https://ecosystem.samcarlton.com/technical-debt)).

**For example:** To fix a [bug](https://ecosystem.samcarlton.com/bug), a [developer](https://ecosystem.samcarlton.com/software-engineer) first writes a test that shows the bug, watches it fail, fixes the code until it passes, then tidies up.

## Connects to (4)

- [Testing](https://ecosystem.samcarlton.com/testing): Checking that software does what it should, before your users find the problems for you.
- [Bug](https://ecosystem.samcarlton.com/bug): A mistake in software that makes it behave in a way nobody intended.
- [Technical debt](https://ecosystem.samcarlton.com/technical-debt): Shortcuts taken while building software that save time now but make later changes slower and riskier until someone cleans them up.
- [Pair programming](https://ecosystem.samcarlton.com/pair-programming): Two people writing code together at one screen, one typing and one reviewing and thinking ahead, switching roles often.

Map view: https://ecosystem.samcarlton.com/red-green-refactor