# Why Automated Tests and Which Kinds — Jest, Vitest & Testing Library

Source: https://www.skillbyai.com/en/javascript-testing/f-why

> The testing pyramid, the testing trophy and where component tests fit.

## Tests buy confidence, not coverage numbers

An automated test is code that runs your code and checks the result. Its real job is **confidence**: you can refactor, upgrade dependencies or accept a pull request knowing that important behaviour still works. The classic **testing pyramid** says to write many fast **unit** tests, fewer **integration** tests and very few slow **end-to-end** tests. For frontends, Kent C. Dodds' **testing trophy** shifts the weight: a base of **static** checks (TypeScript, ESLint), some unit tests, the largest share of **integration** tests (several units together, such as a component with its children and hooks), and a few end-to-end tests. This course covers unit, integration and component tests run in Node with a simulated DOM; full-browser end-to-end tests belong to tools like Playwright and Cypress, covered in their own course.

## Confidence you can run on every change

Automated tests let you change code quickly because a machine re-checks behaviour for you in seconds.

![Three ideas: why tests and which kinds, Jest versus Vitest, setting up a runner.](assets/figures/javascript-testing/section-1-map.svg) — Figure 1.1 — From why we test, to choosing a runner, to a working setup.

## Kinds of test in a frontend codebase

What each layer checks and roughly how it runs.

```text
static       TypeScript, ESLint          catches typos and type errors without running code
unit         Jest / Vitest               one function or module in isolation (formatPrice, a reducer)
integration  Jest / Vitest + Testing Lib  several pieces together (a form + validation + API call mocked with MSW)
component    Jest / Vitest + Testing Lib  a rendered component in jsdom / happy-dom, driven like a user
end-to-end   Playwright / Cypress        the real app in a real browser against a real or staged backend

rule of thumb: the closer a test is to how users use the app, the more confidence it gives,
               but the slower and more expensive it tends to be
```

## Smoke alarms, not inspectors

Tests are like smoke alarms in every room: cheap, always on, and they shout the moment something starts burning, long before a yearly inspection (manual QA) would notice.

**Quiz:** What does the testing trophy emphasise most for frontend apps?

- [ ] Snapshot tests of every component
- [ ] Only end-to-end tests in a real browser
- [x] Integration tests that exercise several units together
- [ ] Unit tests of private helper functions only

*Answer:* Integration tests that exercise several units together. Integration tests give a good balance of confidence and speed.