A test suite has two jobs: fail when behaviour breaks, and stay green when it doesn’t. Most teams focus on the first and forget the second. Then someone renames a private function, forty tests go red, nobody’s behaviour changed, and the lesson the team learns is “tests slow us down”.
\nHere is Splitwise-lite’s splitEvenly, which divides a bill in cents between people. Leftover cents go to the first people in the list, so the result is fair (shares differ by at most one cent) and deterministic:
function splitEvenly(totalCents, people) {\n if (!Number.isInteger(people) || people < 1) {\n throw new RangeError('people must be a positive integer');\n }\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\nconsole.log(splitEvenly(1000, 3)); // $10.00 three ways\nconsole.log(splitEvenly(1001, 4));\nconsole.log(splitEvenly(2, 3));Its behaviour is everything a caller can observe: the array it returns, the error it throws for zero people. Its implementation is how: Math.floor, the % operator, Array.from, the variable names. You could rewrite the body with a loop, or by handing out cents one at a time, and no caller would notice.
A test that checks behaviour survives all of those rewrites. A test that checks implementation breaks on every one of them, even though nothing a user cares about changed. That is a false alarm, and false alarms are expensive: each one costs a debugging session, and enough of them teach people to rerun or delete red tests without reading them.
\nThese are real patterns I have deleted from codebases:
\n// Spying on Math.floor: breaks if you switch to integer division another way\nconst floor = vi.spyOn(Math, 'floor');\nsplitEvenly(1000, 3);\nexpect(floor).toHaveBeenCalledWith(1000 / 3);\n\n// Testing an exported private helper: breaks when you inline or rename it\nexpect(_remainderFor(1000, 3)).toBe(1);\n\n// Snapshotting the source-shaped output of a debug helper nobody calls\nexpect(describeSplit(1000, 3)).toMatchSnapshot();Each one passes today and tells you nothing a behaviour test wouldn’t. Each one will fail the day someone improves the code.
\nStart from what a caller relies on. For splitEvenly that is:
Points 2 and 3 are invariants: they hold for every valid input, so you can check them over several inputs at once:
\nimport { describe, test, expect } from 'vitest';\nimport { splitEvenly } from './split.js';\n\nconst sum = (xs) => xs.reduce((a, b) => a + b, 0);\n\ndescribe('splitEvenly', () => {\n test('never loses or invents a cent', () => {\n for (const [total, people] of [[1000, 3], [1001, 4], [2, 3], [0, 5]]) {\n expect(sum(splitEvenly(total, people))).toBe(total);\n }\n });\n\n test('gives the leftover cents to the first people', () => {\n expect(splitEvenly(1001, 4)).toEqual([251, 250, 250, 250]);\n });\n\n test('refuses to split between zero people', () => {\n expect(() => splitEvenly(1000, 0)).toThrow(RangeError);\n });\n});The sum invariant is the most valuable line in the file. A version that drops the remainder fails it. So does an off-by-one that hands out one cent too many. It doesn’t care how the shares are computed, only that money is conserved.
\n\nBehaviour tests can still be exact. toEqual([251, 250, 250, 250]) pins the documented order of extra cents, and that is behaviour because callers rely on it. The question is never “exact or loose?” but “would a user or caller notice if this changed?” If yes, assert it precisely. If no, don’t assert it at all.
Sometimes a change to the code should change a test, and it helps to know which situation you are in. If the public contract changed (the function now returns objects instead of numbers, or the extra cents now go to the payer), the test was right to fail, and you update it on purpose, ideally before changing the code. If the contract is the same and a test fails anyway, the test was coupled to the implementation: rewrite it against the contract and delete the old one. A healthy suite makes that question easy to answer, because every test name states a promise the code makes.
\nIn the exercise, write behaviour tests for splitEvenly that catch four realistic bugs. The next lesson is about finding the inputs that expose bugs like these.
You rewrite splitEvenly from Array.from to a plain for loop. Its outputs are identical for every input. Two tests go red. What does that tell you about those tests?
Which single assertion would catch the most different bugs in splitEvenly(totalCents, people)?
expect(shares).toHaveLength(people)","why":"It is useful, but a version that loses the leftover cents still returns the right number of shares."},{"text":"expect(Math.max(...shares) - Math.min(...shares)).toBeLessThanOrEqual(1)","why":"It catches unfair splits, but a version that drops the remainder gives everyone the same share and passes it."},{"text":"expect(shares.reduce((a, b) => a + b, 0)).toBe(totalCents)","why":"Correct. Losing a cent, inventing a cent and mishandling the remainder all break the sum. It is the invariant money code must never violate."}],"answer":2},{"q":"A teammate exports _remainderFor(total, people) from split.js so it can be unit tested directly. What’s the better approach?
splitEvenly, using inputs that leave a remainder.","why":"Correct. The helper only matters because of what splitEvenly returns, so testing through the public function covers it and leaves you free to delete or rename the helper."},{"text":"Copy the helper into the test file and test the copy.","why":"Then the test checks a copy that can drift from the real code; it would stay green while the real helper breaks."}],"answer":1}],"exercise":{"kind":"web","mode":"test","subject":"// Splits a bill in integer cents between people.\n// Contract:\n// - one share per person\n// - the shares add up exactly to totalCents\n// - shares differ by at most one cent\n// - leftover cents go to the FIRST people in the list\n// - fewer than one person throws a RangeError\nfunction splitEvenly(totalCents, people) {\n if (!Number.isInteger(people) || people < 1) {\n throw new RangeError('people must be a positive integer');\n }\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","mutants":[{"id":"drops-remainder","code":"// Splits a bill in integer cents between people.\n// Contract:\n// - one share per person\n// - the shares add up exactly to totalCents\n// - shares differ by at most one cent\n// - leftover cents go to the FIRST people in the list\n// - fewer than one person throws a RangeError\nfunction splitEvenly(totalCents, people) {\n if (!Number.isInteger(people) || people < 1) {\n throw new RangeError('people must be a positive integer');\n }\n const base = Math.floor(totalCents / people);\n const remainder = totalCents % people;\n return Array.from({ length: people }, (_, i) => (base));\n}\n"},{"id":"extra-cent","code":"// Splits a bill in integer cents between people.\n// Contract:\n// - one share per person\n// - the shares add up exactly to totalCents\n// - shares differ by at most one cent\n// - leftover cents go to the FIRST people in the list\n// - fewer than one person throws a RangeError\nfunction splitEvenly(totalCents, people) {\n if (!Number.isInteger(people) || people < 1) {\n throw new RangeError('people must be a positive integer');\n }\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"},{"id":"remainder-last","code":"// Splits a bill in integer cents between people.\n// Contract:\n// - one share per person\n// - the shares add up exactly to totalCents\n// - shares differ by at most one cent\n// - leftover cents go to the FIRST people in the list\n// - fewer than one person throws a RangeError\nfunction splitEvenly(totalCents, people) {\n if (!Number.isInteger(people) || people < 1) {\n throw new RangeError('people must be a positive integer');\n }\n const base = Math.floor(totalCents / people);\n const remainder = totalCents % people;\n return Array.from({ length: people }, (_, i) => (i >= people - remainder ? base + 1 : base));\n}\n"},{"id":"zero-people","code":"// Splits a bill in integer cents between people.\n// Contract:\n// - one share per person\n// - the shares add up exactly to totalCents\n// - shares differ by at most one cent\n// - leftover cents go to the FIRST people in the list\n// - fewer than one person throws a RangeError\nfunction splitEvenly(totalCents, people) {\n if (!Number.isInteger(people) || people < 0) {\n throw new RangeError('people must be a positive integer');\n }\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"}],"starter":{"js":"const sum = (xs) => xs.reduce((a, b) => a + b, 0);\n\ndescribe('splitEvenly', () => {\n test('returns one share per person', () => {\n expect(splitEvenly(1000, 3)).toHaveLength(3);\n });\n\n // Test the rest of the contract in the subject's comment.\n});\n"},"solution":{"js":"const sum = (xs) => xs.reduce((a, b) => a + b, 0);\n\ndescribe('splitEvenly', () => {\n test('returns one share per person', () => {\n expect(splitEvenly(1000, 3)).toHaveLength(3);\n });\n\n test('never loses or invents a cent', () => {\n for (const [total, people] of [[1000, 3], [1001, 4], [2, 3], [900, 3], [0, 4]]) {\n expect(sum(splitEvenly(total, people))).toBe(total);\n }\n });\n\n test('keeps shares within one cent of each other', () => {\n const shares = splitEvenly(1001, 4);\n expect(Math.max(...shares) - Math.min(...shares)).toBeLessThanOrEqual(1);\n });\n\n test('gives the leftover cents to the first people', () => {\n expect(splitEvenly(1001, 4)).toEqual([251, 250, 250, 250]);\n expect(splitEvenly(1000, 3)).toEqual([334, 333, 333]);\n });\n\n test('refuses to split between zero people', () => {\n expect(() => splitEvenly(1000, 0)).toThrow(RangeError);\n });\n});\n"},"checks":[{"id":"passes","suite":"subject"},{"id":"catches-drops-remainder","suite":"drops-remainder"},{"id":"catches-extra-cent","suite":"extra-cent"},{"id":"catches-remainder-last","suite":"remainder-last"},{"id":"catches-zero-people","suite":"zero-people"}],"title":"Behaviour tests for splitEvenly","prompt":"The subject’s comment lists splitEvenly’s contract. Write tests for that contract (not for how the function is written) until your suite passes on the real code and catches four hidden bugs:
A sum helper is already in the starter.
expect(sum(splitEvenly(1000, 3))).toBe(1000).","For the order rule, compare the whole array: splitEvenly(1001, 4) must equal [251, 250, 250, 250]. For zero people, use expect(() => splitEvenly(1000, 0)).toThrow(RangeError)."],"explanation":"The sum invariant does the heavy lifting: dropping the remainder makes the total too small and the off-by-one makes it too big, so one assertion kills both. The order rule is part of the documented contract, so asserting the exact array is a behaviour test, not an implementation test; it is the only way to catch the version that favours the last people, which still conserves money and stays fair. The zero-people case is a boundary that silently returned [] in the buggy version, and a caller would have divided a bill between nobody. None of these tests mention Math.floor, % or Array.from, so you can rewrite the function freely and they stay green.