Testing Mindset

The big question: “Why we test, assertions, the test pyramid, Vitest”

but why do we need this?

Every change to an app risks silently breaking something that used to work. Re-checking everything by hand after every change is slow, mind-numbing, and error-prone — so companies pay engineers to teach machines to do the checking instead. That job is the one you’re heading for, and this phase is its way of thinking.

in plain words

Software breaks quietly: a fix over here snaps something over there (a regression), and nobody notices until a customer does. Testing is the craft of noticing first — writing checks that re-verify the important promises automatically, every single time the code changes.

A test has a simple rhythm called Arrange–Act–Assert: set the stage, do the thing, check the result. An assertion is the checking part: “I expect the total to be 115 — is it?” Green means the promise holds; red means you caught a bug before a user did.

You’ll also learn the strategy layer — the testing pyramid — which explains why teams write many small fast tests and fewer big slow ones, and exactly where your future Playwright tests sit in that picture.

words you’ll own after this

test case

One automated check of one promise: “given this input, the app should do that.”

assertion

The moment of truth inside a test: expect(actual).toBe(expected).

regression

Something that used to work, broken by a later change. The main monster tests exist to catch.

unit / integration / E2E

Test sizes: one function alone; several parts together; the whole app driven like a real user (that’s Playwright).

test runner

The tool that finds your tests, runs them, and reports green/red — Vitest here, Playwright’s runner later.

mock

A cardboard stand-in for a real dependency (like a payment server) so tests stay fast, cheap and predictable.

after this phase, you can…

✓Explain to anyone why automated tests exist (in money terms)
✓Structure a test with Arrange–Act–Assert
✓Write and run real Vitest tests and read their output
✓Place any testing task on the pyramid and justify it

this phase’s lab — see it move

✏️ This phase’s interactive lab is still being drawn — it arrives together with the phase’s lessons.

the lessons

10.1
Why software breaks
Watch a regression happen mechanically — then price it: desk, review, QA, 2am.
10.2
The testing pyramid
Unit / API / E2E — a 1000× speed spread. The shape is a budget, not a diagram.
10.3
Anatomy of a test
Arrange–Act–Assert on five plain lines — and where expected values MUST come from.
10.4
Assertions
toBe vs toEqual — 4.6’s addresses pay off in the twin trap. Build both yourself.
10.5
Vitest hands-on
describe/it/expect, reading red like a letter, exit codes, watch mode — then build the runner.
10.6
Test doubles & a taste of TDD
Stub, spy (a closure!), mock, fake — double at boundaries only. One red-green-refactor lap.
10.7
Checkpoint: test the tip calculator
3.11’s brain under guard: suite, sabotage, cascade, catch — red to green in seconds.