Using observability (logs, metrics, traces) as part of your testing strategy

Most testing focuses on the output: did the API return the right response? But I've started treating observability as a first-class part of my test assertions. **What this looks like in practice:** For a payment flow test, beyond asserting the API response, I now also assert: - The expected logs were emitted (using our log aggregation API in test mode) - The expected metrics incremented (our metrics client exposes a test flush method) - No error-level logs were emitted for a successful transaction **Why this matters:** Silent failures. Code that returns 200 but doesn't emit the expected events. Correct responses but incorrect internal state. These only surface in production monitoring without this approach. It requires that your observability is testable (structured logs, flushable metrics). But if it is, you're testing the contract with your ops team, not just the contract with clients.