Last spring a teammate of mine changed one line in a bill-splitting helper: Math.round became Math.floor, to “fix” a share that looked one cent too high. Every screen still worked. Three weeks later a user noticed their group’s balances no longer added up to zero, and nobody could say which of 200 commits had done it. One three-line test would have failed within a second of that change.
That is what tests buy you: the confidence to change code quickly. Without them, every refactor is a gamble and every release needs someone clicking through the app. With good ones, you change the code, run the suite, and know.
\nStrip away the frameworks and a test is code that runs your code and throws when the result is wrong:
\nfunction splitEvenly(totalCents, people) {\n const base = Math.floor(totalCents / people);\n const remainder = totalCents % people;\n return Array.from({ length: people }, (_, i) => (i < remainder ? base + 1 : base));\n}\n\nconst shares = splitEvenly(1000, 3);\nconst sum = shares.reduce((a, b) => a + b, 0);\nif (sum !== 1000) throw new Error(`Expected shares to add up to 1000, got ${sum}`);\nconsole.log('PASS shares add up to the total', shares);Vitest, Jest and Playwright add a lot on top: nice failure messages, watch mode, parallel runs, browsers. Underneath, expect(sum).toBe(1000) is an if that throws.
Every test is code you maintain. It takes time to write, CI minutes to run, and attention when it fails. A test that fails when nothing is broken (a flaky or brittle test) is worse than no test: people learn to ignore red builds. So the question is never “how many tests?” but how much confidence per minute of CI each one buys.
\nThe testing trophy is a popular way to picture the layers and how much of each to write:
\nThe rule I use daily: pick the cheapest test that would fail if the thing you are worried about broke.
\nThe running project is Splitwise-lite, a bill-splitting module for a group trip: parse amounts, split bills, add tips, compute who owes whom and settle up, plus a small UI and a network layer. In the playground you get working code and write tests against it. Then the checker runs your tests against deliberately broken copies (a wrong rounding, an off-by-one, swapped arguments) and your tests must catch each one. Passing on good code is half the job; failing on bad code is the other half.
\nBefore installing anything, build the core idea yourself in the exercise below: an assertion that throws and a runner that catches.
\n","toc":[{"id":"sec-1","text":"What a test is","level":2},{"id":"sec-2","text":"Tests cost something too","level":2},{"id":"sec-3","text":"The testing trophy","level":2},{"id":"sec-4","text":"What you build in this course","level":2}],"takeaways":["A test is code that runs your code and throws when the result is wrong; every framework is a nicer wrapper around that idea.","Tests buy you the confidence to change code quickly; a test that never catches a bug and never documents anything costs more than it earns.","The testing trophy has four layers (static analysis, unit, integration, end-to-end), with integration tests usually giving the most confidence per minute of CI.","Choose the cheapest test that would fail if the thing you are worried about broke."],"further":[{"title":"Vitest — Why Vitest","url":"https://vitest.dev/guide/why"},{"title":"Playwright — Getting started","url":"https://playwright.dev/docs/intro"},{"title":"Testing Library — Guiding principles","url":"https://testing-library.com/docs/guiding-principles"}],"quiz":[{"q":"Splitwise-lite rounds each person’s share to whole cents. Which test gives you the fastest, most precise signal that the rounding is right?
","options":[{"text":"An end-to-end test that adds an expense in the browser and reads the balance.","why":"It would catch the bug, but it is slow, needs a running app and points at the whole stack when it fails, not at the rounding function."},{"text":"A unit test that calls the split function with 1000 cents and 3 people.","why":"Correct. Rounding is pure logic with many edge cases, so a millisecond unit test is the cheapest test that fails exactly when the rounding breaks."},{"text":"A TypeScript type check on the function signature.","why":"Types confirm the function takes and returns numbers, but they cannot tell 334 from 333; rounding is a value question, not a type question."}],"answer":1},{"q":"What does a test framework fundamentally do when an assertion fails?
","options":[{"text":"It edits the source code so the assertion passes next time.","why":"No framework changes your code; a failing test is information for you to act on."},{"text":"It logs a warning and keeps the test green.","why":"A test that stays green on a failed assertion would be useless; frameworks mark the test as failed."},{"text":"The assertion throws, the runner catches the error, marks that test failed and moves on.","why":"Correct.expect(...).toBe(...) throws an error on mismatch; the runner wraps each test in a try/catch and reports it."}],"answer":2},{"q":"Your team’s end-to-end suite takes 40 minutes and fails randomly about once a day. Which change most improves confidence per minute of CI?
","options":[{"text":"Move most of the logic checks down to integration and unit tests, keeping a few end-to-end tests for critical flows.","why":"Correct. Lower layers check the same logic in milliseconds without browser flakiness; a handful of end-to-end tests still prove the pieces connect."},{"text":"Add automatic retries until every test passes.","why":"Retries hide flakiness instead of fixing it and make the suite even slower; real bugs that fail intermittently get retried away too."},{"text":"Delete the end-to-end suite and rely on unit tests only.","why":"Unit tests can all pass while the app is broken, for example when the form never calls the function they test. You still want a few end-to-end tests."}],"answer":0}],"exercise":{"kind":"web","mode":"js","starter":{"js":"// An assertion: throw an Error when actual !== expected.\nfunction expectEqual(actual, expected) {\n // your code\n}\n\n// A runner: run fn, log PASS or FAIL, never let one failure stop the others.\nfunction test(name, fn) {\n // your code\n}\n\ntest(\"two plus two\", () => expectEqual(2 + 2, 4));\ntest(\"deliberately wrong\", () => expectEqual(0.1 + 0.2, 0.3));\n"},"solution":{"js":"function expectEqual(actual, expected) {\n if (actual !== expected) {\n throw new Error(`Expected ${expected} but received ${actual}`);\n }\n}\n\nfunction test(name, fn) {\n try {\n fn();\n console.log(`PASS ${name}`);\n } catch (error) {\n console.log(`FAIL ${name}: ${error.message}`);\n }\n}\n\ntest(\"two plus two\", () => expectEqual(2 + 2, 4));\ntest(\"deliberately wrong\", () => expectEqual(0.1 + 0.2, 0.3));\n"},"checks":[{"id":"equal-passes","test":"try { expectEqual(5, 5); expectEqual(\"a\", \"a\"); return true; } catch { return false; }"},{"id":"unequal-throws","test":"try { expectEqual(333, 334); return false; } catch (e) { return e instanceof Error && String(e.message).includes(\"333\") && String(e.message).includes(\"334\"); }"},{"id":"logs-pass","test":"test(\"check-pass-case\", () => expectEqual(1, 1)); return logs.includes(\"PASS check-pass-case\");"},{"id":"logs-fail","test":"test(\"check-fail-case\", () => expectEqual(1, 2)); return logs.some((l) => l.startsWith(\"FAIL check-fail-case\") && l.includes(\"2\"));"},{"id":"keeps-going","test":"try { test(\"check-boom\", () => { throw new Error(\"boom\"); }); } catch { return false; } return logs.some((l) => l.startsWith(\"FAIL check-boom\"));"}],"title":"Build a ten-line test runner","prompt":"Write the two functions every test framework is built on.
\nexpectEqual(actual, expected) does nothing when the values are strictly equal (===) and throws an Error otherwise. The message must include both values, for example Expected 334 but received 333.test(name, fn) calls fn. If it returns normally, log PASS <name>. If it throws, log FAIL <name>: <error message> and do not rethrow, so the next test still runs.Run it: the second test fails on purpose, because 0.1 + 0.2 is not exactly 0.3 in JavaScript.
expectEqual needs one if and one throw new Error(...). Use a template literal to put both values in the message.","test needs a try { … } catch (error) { … } around the call to fn().","Log with console.log(`PASS ${name}`) after fn() inside try, and console.log(`FAIL ${name}: ${error.message}`) inside catch."],"explanation":"This is the core of Vitest, Jest and every other runner: an assertion is an if that throws, and a test is a function the runner calls inside try/catch. Catching the error is what lets one failing test be reported without stopping the rest of the suite. Real frameworks add better messages (diffs of objects), async support, hooks, watch mode and parallel runs, but the contract is identical: a test passes when its function finishes without throwing. Notice also the deliberate failure: 0.1 + 0.2 is 0.30000000000000004, which is exactly why Splitwise-lite stores money as integer cents.