Test-driven development has a reputation problem. Some people treat it as a religion; others dismiss it after one painful kata. I treat it as a tool, and like any tool it’s excellent for some jobs and wrong for others. For the core money logic in Splitwise-lite, it’s the best tool I know.
\nTDD is a short loop, usually a minute or two per turn:
\nWhy insist on seeing red? Because a test you’ve never seen fail might not be able to fail. It might call the wrong function, assert on a variable that’s always truthy, or never actually check anything (a missing await, a .skip left in place). Red first is cheap proof that the test is wired up.
Splitwise-lite needs settleUp(balances): given who is owed and who owes (in cents), return a short list of transfers that brings everyone to zero. Here is how the first few turns go, with Vitest in watch mode so every save reruns the tests.
Turn 1, the simplest case. Nobody owes anything:
\ntest('needs no transfers when everyone is settled', () => {\n expect(settleUp({ Ana: 0, Ben: 0 })).toEqual([]);\n});Red: settleUp is not defined. Green: export function settleUp() { return []; }. Yes, that’s the whole implementation for now. It’s honest about what the tests demand.
Turn 2, one debt. The next test forces real behaviour:
\ntest('the debtor pays the creditor', () => {\n expect(settleUp({ Ana: 500, Ben: -500 })).toEqual([\n { from: 'Ben', to: 'Ana', amountCents: 500 },\n ]);\n});Green might pair the one negative balance with the one positive balance. Still small.
\nTurn 3, several people. Now a hard-coded pairing breaks, and the general algorithm earns its place: sort debtors and creditors by amount, repeatedly move the smaller of the two current amounts, advance whichever side reaches zero. For assertions, use properties where several answers are valid: applying the transfers brings every balance to zero, every amount is positive, and there are at most people - 1 transfers.
Turn 4, invalid input. Balances that don’t add up to zero mean a bug upstream; settleUp should refuse rather than invent money: expect(() => settleUp({ Ana: 500, Ben: -400 })).toThrow().
Then refactor: name the sort comparator, extract a helper, make it read well. The tests let you change the shape of the code without fear, which is the real payoff.
\n\nThe most valuable everyday use of TDD has nothing to do with new features. When a bug is reported:
\nThis works even in codebases that were never written test-first, and it turns every bug report into a permanent improvement of the suite.
\nTDD assumes you know what “correct” means. When you don’t, writing tests first just writes down guesses:
\nIn the exercise you play the green half of the cycle: the tests for settleUp are written (they’re the checks), and you write the code that makes them pass. In the next two lessons, you’ll measure how good those tests are.
You write a test for a new case and it passes immediately, before you change any code. What should you do?
","options":[{"text":"Commit it; a passing test is the goal.","why":"A test you’ve never seen fail might not test what you think, for example because it calls the wrong function or asserts on the wrong value."},{"text":"Temporarily break the code (or the expectation) to confirm the test can fail, then decide whether the case was already covered.","why":"Correct. Either the behaviour already exists (fine, keep the test as documentation) or the test is broken; you need to know which."},{"text":"Delete the test, since TDD tests must start red.","why":"The test might be valuable documentation of a case; the point is to verify it can fail, not to throw it away."}],"answer":1},{"q":"A user reports that settling up a group with one person owing $0.01 crashes. What’s the TDD way to fix it?
","options":[{"text":"Fix the code, then add a test for the case so it stays fixed.","why":"Better than no test, but you never saw the test fail, so you can’t be sure it reproduces the reported bug."},{"text":"Add atry/catch around the settle-up call so the crash can’t reach the user.","why":"That hides the bug instead of fixing it, and the balances are still wrong."},{"text":"Write a test that reproduces the crash and watch it fail, then fix the code until it passes.","why":"Correct. The red test proves you’ve reproduced the bug; the green one proves the fix; the test then guards against regressions forever."}],"answer":2},{"q":"Which task is the weakest fit for strict test-first development?
","options":[{"text":"Implementing the rounding rules for splitting a bill.","why":"Clear inputs and outputs with tricky edge cases are where TDD is strongest."},{"text":"Fixing a reported bug in the balance calculation.","why":"Reproducing a bug with a failing test first is one of TDD’s most valuable uses."},{"text":"Trying three layouts for the balances screen to see which one users understand.","why":"Correct. When you don’t know what you’re building yet, tests written first describe guesses; spike first, then test what you keep."}],"answer":2}],"exercise":{"kind":"web","mode":"js","starter":{"js":"// Make the tests (the checks) pass, one at a time.\n// balances: { name: cents }. Positive = is owed money, negative = owes.\n// Return transfers: [{ from, to, amountCents }].\nfunction settleUp(balances) {\n return [];\n}\n\nconsole.log(settleUp({ Ana: 500, Ben: -500 }));\n"},"solution":{"js":"// Make the tests (the checks) pass, one at a time.\n// balances: { name: cents }. Positive = is owed money, negative = owes.\n// Return transfers: [{ from, to, amountCents }].\nfunction settleUp(balances) {\n const entries = Object.entries(balances);\n const sum = entries.reduce((total, [, cents]) => total + cents, 0);\n if (sum !== 0) throw new Error('Balances must add up to zero');\n\n const debtors = [];\n const creditors = [];\n for (const [name, cents] of entries) {\n if (cents < 0) debtors.push({ name, cents: -cents });\n else if (cents > 0) creditors.push({ name, cents });\n }\n const largestFirst = (a, b) => b.cents - a.cents || a.name.localeCompare(b.name);\n debtors.sort(largestFirst);\n creditors.sort(largestFirst);\n\n const transfers = [];\n let d = 0;\n let c = 0;\n while (d < debtors.length && c < creditors.length) {\n const amountCents = Math.min(debtors[d].cents, creditors[c].cents);\n transfers.push({ from: debtors[d].name, to: creditors[c].name, amountCents });\n debtors[d].cents -= amountCents;\n creditors[c].cents -= amountCents;\n if (debtors[d].cents === 0) d += 1;\n if (creditors[c].cents === 0) c += 1;\n }\n return transfers;\n}\n\nconsole.log(settleUp({ Ana: 500, Ben: -500 }));\nconsole.log(settleUp({ Ana: 1500, Ben: -1000, Cai: -500 }));\n"},"checks":[{"id":"settled","test":"const t = settleUp({ Ana: 0, Ben: 0 }); return Array.isArray(t) && t.length === 0 && Array.isArray(settleUp({})) && settleUp({}).length === 0;"},{"id":"two-people","test":"const t = settleUp({ Ana: 500, Ben: -500 }); return Array.isArray(t) && t.length === 1 && t[0].from === 'Ben' && t[0].to === 'Ana' && t[0].amountCents === 500;"},{"id":"settles-everyone","test":"const cases = [\n { Ana: 500, Ben: -500 },\n { Ana: 1500, Ben: -1000, Cai: -500 },\n { Ana: -700, Ben: 300, Cai: 400, Dee: 0 },\n { Ana: 2500, Ben: -1000, Cai: -1000, Dee: -1000, Eve: 500 },\n { Ana: -1, Ben: -1, Cai: 2 },\n];\nfor (const b of cases) {\n const left = { ...b };\n const t = settleUp({ ...b });\n if (!Array.isArray(t) || (t.length === 0)) return false;\n for (const x of t) {\n if (!Number.isInteger(x.amountCents) || x.amountCents <= 0) return false;\n if (!(x.from in left) || !(x.to in left)) return false;\n left[x.from] += x.amountCents;\n left[x.to] -= x.amountCents;\n }\n if (Object.values(left).some((v) => v !== 0)) return false;\n}\nreturn true;"},{"id":"few-transfers","test":"const cases = [\n { Ana: 500, Ben: -500 },\n { Ana: 1500, Ben: -1000, Cai: -500 },\n { Ana: -700, Ben: 300, Cai: 400, Dee: 0 },\n { Ana: 2500, Ben: -1000, Cai: -1000, Dee: -1000, Eve: 500 },\n { Ana: -1, Ben: -1, Cai: 2 },\n];\nreturn cases.every((b) => {\n const people = Object.values(b).filter((v) => v !== 0).length;\n const t = settleUp({ ...b });\n return Array.isArray(t) && t.length >= 1 && t.length <= people - 1;\n});"},{"id":"ignores-settled","test":"const t = settleUp({ Ana: -700, Ben: 300, Cai: 400, Dee: 0 }); return Array.isArray(t) && t.length > 0 && t.every((x) => x.from !== 'Dee' && x.to !== 'Dee');"},{"id":"rejects-unbalanced","test":"try { settleUp({ Ana: 500, Ben: -400 }); return false; } catch (e) { return e instanceof Error; }"},{"id":"no-mutation","test":"const b = { Ana: 1500, Ben: -1000, Cai: -500 }; settleUp(b); return b.Ana === 1500 && b.Ben === -1000 && b.Cai === -500 && Object.keys(b).length === 3;"}],"title":"Make the settleUp tests pass","prompt":"This is the green step of TDD: the tests are already written (they’re the checks below), and your job is to make them pass.
\nsettleUp(balances) takes balances in cents ({ Ana: 1500, Ben: -1000, Cai: -500 }: positive means the person is owed money, negative means they owe) and returns transfers such as [{ from: 'Ben', to: 'Ana', amountCents: 1000 }, { from: 'Cai', to: 'Ana', amountCents: 500 }].
The tests require that: settled groups need no transfers; one debtor pays one creditor; applying the transfers brings everyone to zero with positive whole-cent amounts; there are at most people − 1 transfers (counting people with a non-zero balance); settled people never appear; balances that don’t add up to zero throw; and the input object is not modified.
\nWork through the checks in order, running after each change. The starter passes the first one.
\n","hints":["First reject bad input: add up all the balances and throw anError if the sum is not 0.","Split people into debtors (negative balances, stored as positive amounts they owe) and creditors (positive balances). Copy the numbers into new objects so you never change the input.","Loop while both lists have someone: transfer Math.min(debtor.cents, creditor.cents) from the current debtor to the current creditor, subtract it from both, and move to the next debtor or creditor when theirs reaches 0. Sorting both lists largest-first keeps the number of transfers small."],"explanation":"The reference solution checks the sum first, then builds fresh { name, cents } objects for debtors and creditors, which is why the input stays untouched. The loop always transfers the smaller of the two current amounts, so after each transfer at least one person reaches zero and is left behind; that guarantees termination and at most people - 1 transfers. Sorting largest-first is a common heuristic that often produces fewer transfers in practice, but the tests deliberately don’t demand an exact list for groups larger than two, because several answers are correct. That’s a design choice worth copying: when many outputs are valid, assert the properties every valid output has (everyone ends at zero, amounts are positive, the count is small) instead of one specific answer.