How this maps to Vitest

The loop with the try/catch that you wrote in lesson 2 is the test runner. The array of objects with a name and a body is what describe and it produce: describe groups related tests and gives the group a name, it declares a single test with a sentence for a name and a function for a body. Your assertEquals is expect(actual).toEqual(expected). Your createSpy is vi.fn(). There is no fifth thing you have not met.

That is the honest summary of what a test framework is, and it is worth saying plainly because the first encounter with one is otherwise all mystery: functions you did not import appearing to exist, a command that finds your files by itself, output in colours. Underneath, it is a loop, a try/catch and a comparison - the things you built, with the reporting done properly.

This lesson deliberately stops at recognition. Installing a runner, wiring it into a project and reading its configuration belong to the tooling module and to that tool's own documentation, which is where you should go next - a course that paraphrased Vitest's manual would only be a worse copy of it that goes stale.

The first real decision a framework asks of you is one you already understand. toBe compares the way === does - the documentation says it is equivalent to Object.is - so it answers 'are these the same value or the same object'. It is right for numbers, text, true and false, null and undefined, and it is wrong for two separately built objects, which is exactly the trap from lesson 1.

toEqual compares structures: it walks both values recursively and asks whether they hold the same things. That is the grown-up version of the JSON.stringify trick you have been using, without its weaknesses - it does not care about the order the keys were written in, and it can report which property differs rather than handing you two long strings and letting you find the difference yourself.

There is a third, toStrictEqual, and its existence tells you something the JSON trick was hiding. It differs from toEqual in checking keys whose value is undefined, checking array sparseness, and checking that the two objects are of the same type. In other words, toEqual treats a property that is present-but-undefined as equivalent to a property that is absent, and toStrictEqual does not. When that distinction matters in your data, the framework has a matcher for it - and when you were comparing JSON text, you had no way to say it at all.

What you get: it finds the test files for you rather than you maintaining a list; it runs each file in isolation so one file's leftovers cannot reach another; it re-runs only what your last edit affected while you type; it prints a readable difference between two structures instead of two walls of text; it reports which lines of your code were never executed by any test; and it gives you spies, fake clocks and module substitutes that clean themselves up afterwards. Every one of those is something you could build and none of them is something you should.

What it cannot do: decide what is worth testing. A suite of two hundred green tests that all exercise the happy path tells you nothing about the empty basket, and no runner will point that out. The judgement in lesson 3 - zero, one, many, both sides of every boundary - is the part that stays yours, and it is the part that makes the difference between a suite that catches bugs and a suite that only takes time.

It also cannot make a bad test good. A test that asserts on a spy without checking its arguments is just as weak inside a framework as outside it, and a test you have never watched fail is just as untrustworthy. The framework raises the floor on reporting; it does not raise the floor on thinking.

A framework's failure report has four parts, and they answer four questions in a fixed order. The test name says which claim broke. The file and line say where the assertion lives. The expected and received values say how reality differed. The stack trace says how the code got there.

Read them in that order and stop as soon as you know enough. Most failures are solved by the first three: the name tells you what was supposed to happen, and the two values tell you what happened instead. The stack trace matters when the failure came from inside code you did not write, and reading it top to bottom - your file is usually the first line that mentions your own project - is faster than reading the whole thing.

One habit transfers directly from this module: when a test goes red, your first question is not 'what did I break in the code' but 'which of the two - the code or the claim - is wrong'. A failing test is a disagreement, and sometimes the test is the one that is out of date.

describe groups, it declares one test, expect makes a claim, vi.fn() is your spy. toBe is ===, toEqual walks the structure, toStrictEqual also cares about undefined properties and types. A framework buys you discovery, isolation, watch mode, readable diffs and coverage; it does not buy you judgement about what to test. And read a failure in the order it is printed: name, place, expected against received, then the trace.