test-genlisted

# Test Gen Good tests verify behavior, not implementation. They should break when something the user cares about breaks — and only then. ## Before writing tests: understand the contract The contract of a piece of code is what it promises to callers: given these inputs and preconditions, it will produce these outputs or effects. Tests should verify the contract, not the internal mechanics. Ask before writing: 1. What are the public entry points? (functions, methods, endpoints, events) 2. What does each promise to callers? 3. What are the preconditions (what must be true for the code to work correctly)? 4. What are the postconditions (what must be true after it runs)? 5. What invariants must always hold? (e.g., "the list is always sorted after this call") If the contract is unclear, clarify it first. A test that verifies vague behavior is itself vague. ## Choosing the right test level **Unit tests** — verify a single function or class in isolation - Fast, precise, easy to diagnose when they fail - Best for: pure functions, business logic, data transformation, edge case enumeration - Pitfall: over-mocking can make tests verify call sequences rather than behavior **Integration tests** — verify that components work correctly together - Slower, but catch interface mismatches unit tests miss - Best for: database queries, external service calls, message passing between modules - Use a real dependency (test DB, in-memory queue) where possible — mocked interfaces drift from