testing-patternslisted

# Testing Philosophy ## Integration Tests Verify Behavior, Not Internals Integration tests must verify **observable behavior through endpoints**, not implementation details. **Good integration tests:** - Drive endpoints with an HTTP client - Assert status codes and response bodies - Verify side effects (emails sent, database rows created, audit entries logged) - Test cross-cutting concerns (middleware, auth, rate limiting) **Bad integration tests:** - Calling internal service functions for behavior already observable via HTTP - Using DB queries as the primary assertion surface (DB is for post-assertion verification) - Testing internal query functions or utility functions -- those belong in unit tests - Duplicating coverage already exercised by another test ## Prefer Fixture Composition If a test starts with boilerplate setup (register a user, log in, configure a setting), that belongs in a fixture. Test bodies should stay focused on what they're actually testing. Build fixture stacks: `user` -> `logged_in_user` -> `admin_user`. Each level adds one concern. Tests request the level they need. ## Canary Markers for Library Internals When code depends on a library's private or poorly-documented internals, add a **canary test** that asserts the internal's shape directly -- don't rewrite production code to avoid the dependency when doing so would cost real accuracy or capability. The canary turns an upstream rename or shape change into a loud test failure instead of a s