Sandbox endpoint with scoped permissions versus local mock server for Deno integration tests without production credentials

Answer

For CI runs that must never see production credentials, the local mock server approach provides the stronger security and reliability guarantees while still exercising the client code.

Confirmed facts

• Deno blocks network and environment access by default; explicit --allow-net and --allow-env flags are required for any outbound call.
• Permission flags apply to the whole Deno process, so a broad --allow-net weakens the permission leak‑tripwire for all tests in the same run.
• A sandbox endpoint needs third‑party availability and CI‑stored sandbox credentials, which introduces external dependency and secret‑management overhead.
• A local mock server runs entirely in‑process on an ephemeral localhost port; granting only --allow-net=127.0.0.1 keeps the permission surface minimal.

Likely explanation

Because the mock server eliminates external network calls, it removes the risk of leaking sandbox credentials and avoids flaky tests caused by sandbox downtime. It validates that the client builds correct requests and handles responses according to the contract, which is sufficient for most unit‑level integration testing. The sandbox endpoint adds real‑world validation (auth headers, status codes, provider‑specific error bodies) but at the cost of managing secrets and accepting occasional external failures.

Steps for this case

1. In each test file, start an Oak (or std/http) server on a random port using listen({ port: 0 }).
2. Capture the actual port via server.addr().port and construct the base URL http://127.0.0.1:{port}.
3. Inject that URL into the API client under test (e.g., via constructor or setter).
4. Run the test with deno test --allow-net=127.0.0.1 --no-allow-env (or omit --allow-env if the client does not need env vars).
5. Assert on the client’s behavior; the mock server can verify request headers, body, and return programmed responses.

When to consider a sandbox run

If you need to verify provider‑specific error formats, authentication flow, or header handling that your mock does not reproduce, schedule a separate CI job that runs against the sandbox with --allow-net=sandbox.api.example --allow-env=SANDBOX_API_KEY. Keep this job infrequent (e.g., nightly) to limit exposure and flakiness.

Missing diagnostic detail: Do you require validation of provider‑specific error bodies or auth header formats that your current mock cannot emulate? If yes, a periodic sandbox run adds value; otherwise the local mock alone satisfies the security‑reliability balance.