Why and what we test
Automated tests, Arrange-Act-Assert, kinds of tests and what's worth testing.
Updated
What an automated test is
An automated test is code that runs other code and checks that it does what it should. Instead of opening the browser and clicking around by hand after every change, you run a command and find out in seconds whether you broke something.
test('applies the 10% discount', () => {
expect(applyDiscount(100, 'WELCOME10')).toBe(90)
})Exactly what the exercises in this app do: your code + a few checks.
Why it's worth it
- Confidence when changing things — you refactor fearlessly; the tests tell you if you broke something.
- Bugs caught early — in CI, not by users.
- Documentation — tests show how the code is meant to be used.
- Better design — code that's hard to test is usually too tightly coupled.
The anatomy of a test: Arrange – Act – Assert
test('adds the product to the cart', () => {
const cart = createCart() // Arrange — you prepare the data
cart.add({ id: 1, price: 50 }) // Act — you run the code under test
expect(cart.total).toBe(50) // Assert — you check the result
})Kinds of tests
| Kind | Tests | Speed | Confidence | Tools |
|---|---|---|---|---|
| static | types, syntax mistakes, style | instant | basic | TypeScript, ESLint |
| unit | one function / module, in isolation | ms | for logic | Vitest |
| integration | several pieces together (component + hook + data) | fast | high | Vitest + Testing Library |
| end-to-end (E2E) | the real app, in a real browser, like a user | seconds | maximum | Playwright |
The pyramid vs the "trophy"
Classic: the pyramid — many unit tests, fewer integration tests, a few E2E tests.
For the frontend, the modern recommendation (Kent C. Dodds) is the "testing trophy": a static base (TS + ESLint), mostly integration tests, a few unit tests for tricky logic and a few E2E tests for the critical flows (login, checkout).
The reason: an integration test resembles how the user actually uses the app → it gives you more confidence per test written.
What's worth testing
| High priority | Low priority |
|---|---|
| business logic (prices, discounts, validation) | style details, colors |
| critical flows (login, payment, saving) | framework code (Next tests its own routing) |
| fixed bugs (a test so they don't come back) | trivial getters / setters |
| utility functions used everywhere | internal implementation that changes often |
Test behavior, not implementation. A good test doesn't break when you rename an internal variable — only when the visible behavior changes.
Summary
- A test = code that checks other code; Arrange → Act → Assert.
- Static, unit, integration, E2E — each with a different cost and confidence.
- Test behavior; prioritize business logic and critical flows.