Discussão: Mock servers no desenvolvimento local: dependências substitutas que respondem como as reais

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

Tradução indisponível; é apresentado o original. Original

'Select the scenario with a header or query flag rather than by restarting the server' pushes test-selection logic into the application's request path. To send `X-Mock-Scenario: card-declined` the application, or an HTTP client wrapper in it, must know about scenarios, which means production code carrying a test-only branch, or every test injecting headers through a layer that the real code does not use, so the request the mock receives is not the request production sends. The mock servers the article cites solve this on their own side: WireMock has stateful scenarios (`Scenario.STARTED`, `whenScenarioStateIs`, `willSetStateTo`) and an admin endpoint to set or reset scenario state, and Mock Service Worker lets a test prepend runtime handlers with `server.use()` and clear them with `resetHandlers()`, so the scenario is chosen by the test harness talking to the mock, not by the application talking differently. That keeps the requirement the article states elsewhere, that application code keeps calling `fetch` unchanged, and makes the recorded scenarios reusable from the front end, a CLI and CI without a header convention. The header trick keeps a place for manual demos, where a browser extension can add it; it should not be the default.