Lesson 01 · 10 min
Why test: the pyramid and the trophy
Which tests to write, how many, and what makes a test good.
10 minLesson 1 of 5Practice includedAsk AI on any point
Tests are not there to tick a box in CI. They give you the confidence to change code: you refactor, run the suite and know within a minute that nothing broke. Without tests every change to an old module turns into manual checking and fear before a release.
What the course covers
- Lesson 1. Why test, the pyramid and the trophy, what a good test looks like.
- Lesson 2. Unit tests with Vitest: describe, it, expect, the Arrange, Act, Assert pattern, edge cases, table tests.
- Lesson 3. Test doubles: mock, stub, spy, fake. How to replace time and the network, and when mocks lie.
- Lesson 4. Integration tests with a real database in Docker or Testcontainers, a transaction per test, API tests.
- Lesson 5. End to end with Playwright: role locators, auto waiting, fixtures, flaky tests.
Coming next: code coverage and mutation testing, contract tests between services, load testing with k6, and TDD as a way of writing code.
The test pyramid
The classic pyramid says: lots of fast unit tests at the bottom, fewer integration tests in the middle, and very few e2e tests on top. The logic is simple: the higher the level, the slower the test, the more expensive to maintain, and the more often it fails for reasons unrelated to the code. On the other hand, the higher the level, the more confidence it gives, because it checks the system closer to how a person uses it.
- Unit: one function or class with no database and no network. Milliseconds, thousands of them.
- Integration: several parts together: code plus a real database, an HTTP handler plus a service. Seconds.
- E2E: the whole system through a browser or a public API. Seconds to minutes, a few dozen scenarios.
Testing trophy
Kent C. Dodds proposed a different shape, the trophy: static analysis (TypeScript, ESLint) at the base, then some unit tests, integration tests as the widest part, and a few e2e tests on top. The idea is that integration tests give the best ratio of confidence to cost, especially on the frontend, where a component without context proves little.
What makes a test good
- Fast. People stop running slow tests locally, and they become just a filter in CI.
- Isolated. It does not depend on run order, on other tests, or on what was left in the database.
- Readable. The name tells you what broke. A test is documentation of behavior.
- Tests behavior, not implementation. A refactor that does not change behavior should not break tests.
- Deterministic. The same code gives the same result: no randomness, no real time, no external network.
- Vitest: a test runner built on Vite
- Jest: the classic runner for JavaScript
- Jest or Vitest: what to pick for a new project
- Testing interview questions: how this comes up in interviews
Check
Lock it in before you move on
1. Which tests are the most numerous in the classic pyramid?
2. Which part of the testing trophy is the widest?
3. Tests broke after a refactor that did not change behavior. What does this usually mean?
4. Which of these makes a test nondeterministic?