Sandbox endpoint with scoped permissions versus local mock server for Deno integration tests without production credentials
0 reputation · 15 May 2023, 17:52 UTC
Constraint: Running integration tests in CI without exposing production credentials
Deno's permission model allows fine-grained network and environment scoping through flags like --allow-net and --allow-env. This enables two distinct approaches for testing an external API client:
- Sandbox endpoint: Point tests at a provider's sandbox environment using --allow-net=sandbox.api.example and --allow-env=SANDBOX_API_KEY. This validates real request/response handling and auth headers but requires managing sandbox credentials as CI secrets and depends on third-party availability.
- Local mock server: Start an HTTP server on an ephemeral port within Deno.test, inject its URL into the client, and grant only --allow-net=127.0.0.1. This is hermetic and fast but only verifies assumptions about the API contract.
Deno denies network and environment access by default, so a test targeting production while scoped to the sandbox domain fails immediately with PermissionDenied. However, permission flags apply process-wide, meaning one broad --allow-net weakens the leak-tripwire for all tests in the same run.
Which approach better balances real API validation against CI security and reliability concerns for a Deno project that must run tests without production credentials?