testinglisted

# 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. - **Functional** — does it do the right thing, including at its edges and when it fails? For anything with a UI, that includes reachability: tab order lands somewhere sensible, co