My app has rate limiting (or should), and I want tests proving it actually engages instead of just existing in the config. First, inventory what's rate limited: login attempts, password resets, API endpoints, signup, expensive operations like exports or AI calls. Note the configured limits for each. If nothing is rate limited, flag the endpoints that most need it (login, reset, signup, anything that costs money per call) and wait for my decision before proceeding. Then write tests for each limited path: 1. Requests under the limit succeed normally. 2. Requests over the limit are rejected with the correct status (429) and a response that tells the client when to retry, without leaking internal details. 3. The limit applies per the intended key: per IP, per account, or per token, whichever my design says. Two different users shouldn't share a budget, and one user shouldn't be able to multiply their budget by rotating IPs if the limit is per account. 4. The window resets: after the limit period passes, requests succeed again. 5. Legitimate bursts on unrelated endpoints aren't affected (the limiter isn't accidentally global). Control time in the tests where possible so window-reset tests don't take real minutes. When finished, run the suite and report: which limits engage at the right threshold, which are misconfigured, and which critical endpoints have no limit at all.