Testing

House conventions for writing tests and test strategy.

What a test is for

A test earns its place by failing when the behaviour breaks. That single criterion resolves most arguments about what to test: if you cannot name the bug a test would catch, it is coverage theatre — it costs maintenance on every refactor and reports success while the system is broken.

Two consequences run through everything below:

• Assert on outputs — return values, thrown errors, persisted state. A test whose only assertion is expect(mock).toHaveBeenCalledWith(…) verifies the wiring you just wrote, not the behaviour. Rewrite the implementation correctly in a different shape and it fails; break the behaviour while keeping the calls and it passes. Both are the wrong way round.
• Test decisions, not lines. Branches, error translation, state transitions, boundary conditions. A pass-through delegator or a field mapping with no conditional has nothing to get wrong, and a test for it only breaks when someone renames a method.

Coverage percentage is a floor signal — it finds untested files. It cannot tell a valuable test from a vacuous one, so treat a high number as "nothing is empty", never as "the tests are good".

Three modes

Ask all three of a feature; the answers rarely come from the same test.