# Why Test At All?

You've shipped code that worked. Then a week later you changed one small thing, and something *else*
broke - something you didn't even touch. You didn't find out until a user did. That sinking feeling, the
"what else did I just break?" dread every time you open a file that's already working - that's the feeling
this guide is about removing.

Most people meet testing as a chore: a box to tick, a thing your senior nags you about, extra code that
doesn't ship to users. This guide takes the opposite angle. Before you learn *how* to write a test, you're
going to understand *why* tests exist - and once that clicks, testing stops feeling like homework and starts
feeling like the thing that finally lets you relax.

## How to read this
- **Just want the gist?** Read [Phase 1: Tests Are a Safety Net](01-tests-are-a-safety-net.md) - it's the
  whole emotional core of why testing is worth it.
- **Want it to fully make sense?** Read in order. Each phase builds on the last: first *why* tests matter,
  then *what a test actually is*, then *what's actually worth testing* so you don't overdo it.

## The phases
1. **[Tests Are a Safety Net](01-tests-are-a-safety-net.md)** - the real value of a test: changing working
   code *without fear*, because something will shout if you break it.
2. **[What a Test Actually Is](02-what-a-test-actually-is.md)** - demystified: a tiny program that runs your
   real code with known inputs and checks the result, shown passing and failing.
3. **[What's Worth Testing (Straight Talk)](03-whats-worth-testing.md)** - the cost/benefit: what to test, what to
   skip, and why chasing 100% coverage can make things worse.

> This is the **"why"** of testing - the mental model. The **"how"** - actually sitting down and writing one -
> lives in [Your First Unit Test](/guides/your-first-unit-test). The map of the different *kinds* of tests
> lives in [Unit, Integration, and E2E](/guides/unit-integration-e2e). Read this one first; those two will
> make far more sense afterward.
