Test mode

What it is for#

The awkward part of integrating an analytics API is that the interesting responses need data, and data needs a connected ad account and a few days of ingestion. A test key removes that dependency from your build.

• Write and run your integration before any account is connected.
• Run integration tests in CI without a live key, without network cost and without spending a production quota.
• Reproduce a response shape in a bug report without pasting a customer’s numbers into an issue.

What is the same#

Everything a client codes against: paths, parameters, validation, response shapes, error envelope and status codes. A parameter that would be rejected on a live key is rejected on a test key.

What is different#

• The rows are fabricated. Deterministic, so the same request returns the same numbers, which is what makes them usable in an assertion.
• meta.simulated is true. On every response, without exception.
• The limiter fails open. If the rate limiter cannot be read, a test key is allowed through rather than refused. It costs nothing and touches nothing, so breaking a test suite to protect it would protect nothing. Live keys do the opposite.

Assert on the flag#

The flag is worth checking rather than ignoring. It catches both directions of the same mistake: a test run that reached production data, and a production deploy still holding a test key and quietly reporting invented numbers.

const res = await cresva.v1.getMetrics({ ... }); // Catches the deploy that is quietly pointed at a live key, and the one// that is quietly pointed at a test key in production.if (process.env.NODE_ENV === "test" && !res.meta.simulated) {  throw new Error("Test run reached live data. Check CRESVA_API_KEY.");}

# CI, where no ad account is connected and nothing should cost anythingCRESVA_API_KEY=cresva_sk_test_XXXXXXXXXXXXXXXX npm test