Stub at the Network Boundary vs. Test-Mode Config Inside the Extension

When integration-testing a VS Code extension that calls a remote service, the team must decide where to enforce the credential-free contract. One approach runs a local stub server that asserts the exact request shape the extension sends; the extension points at the stub via a test-scoped endpoint setting. The alternative adds a test-only configuration path inside the extension that bypasses authentication parsing and returns canned responses, activated by a dedicated setting such as extension.testMode.

Both the Extension Test Runner and @vscode/test-electron can launch the extension against either arrangement, but they do not inject secrets. The stub approach keeps the network boundary honest and reproduces the same code path used in production, yet it cannot reveal tenant-level policy errors or real-service latency. The internal test mode exercises configuration handling and authentication parsing logic, but it diverges from the production request flow and may mask serialization bugs.

The constraint is that CI must run with zero production credentials present, and the test must fail loudly if the extension accidentally falls back to a default endpoint.

• Which approach gives higher confidence that the production request contract is honored without ever shipping a secret?
• How should the test suite verify that missing configuration fails explicitly rather than silently contacting a default endpoint?