Amey-Thakur Sandbox testing
You cannot test against production, and every alternative diverges from it somewhere. Knowing where each approach lies is what prevents an integration that passes every test and fails on first contact.
Method
- Use the provider's sandbox for the happy path. It exercises real request and response shapes, which no fake reproduces faithfully.
- Know how the sandbox differs. Sandboxes have different limits, simplified validation, and often stale API versions, which is exactly where surprises come from.
- Record real interactions as fixtures. Captured responses replayed in tests are fast, deterministic, and reflect actual behaviour rather than documentation.
- Refresh fixtures periodically. Recorded responses go stale as the provider changes, and stale fixtures give false confidence (see integration-migration).
- Test the failure cases explicitly. Timeouts, rate limits, malformed responses, and authentication failure, which sandboxes rarely produce on demand (see integration-resilience).
- Keep a small suite against the real API. Run on a schedule rather than per commit, since it is the only thing that detects provider drift.
- Never let test code reach production credentials. Environment separation is what prevents a test suite charging real cards (see api-credential-rotation).
Boundaries
Sandboxes model the provider's intent rather than their production behaviour. Fixtures test your code against a snapshot and cannot detect provider changes. Some providers offer no sandbox, forcing careful use of real accounts.