Which layer should I stub when testing a Remix integration without production credentials?
0 reputation · 28 Mar 2024, 01:46 UTC
I'm building integration tests for a Remix v2 app whose loaders call a third-party API that requires credentials I don't want anywhere near CI. The goal is realistic coverage of the route components and their data flow using only synthetic data.
The Remix testing docs describe createRemixStub from @remix-run/testing, where I supply stub loaders returning canned JSON. That works, but it bypasses my real loader code entirely, including serialization, headers, and error-status handling. The alternative I keep seeing is keeping the real loaders and intercepting their outbound fetch calls at the network layer with something like MSW, plus injecting fake env vars in the test setup instead of loading production .env files.
A complicating factor: with the React Router 7 transition, the helper names and import paths differ (createRemixStub vs createRoutesStub), so whatever convention I pick now may need to migrate.
Which stubbing layer gives the best fidelity-to-maintenance tradeoff for credential-free integration tests? Does mixing both approaches in one suite cause problems? And does the choice change meaningfully if the app will move to React Router 7?