Mocking API requests with @storybook/addon-msw: inconsistent mock availability in test‑runner

Mocking API requests with @storybook/addon-msw

When integrating a component that fetches data from an external API, we want to run Storybook stories and the Storybook test‑runner without exposing production credentials. The @storybook/addon‑msw addon intercepts network requests in the browser, but the test‑runner executes stories in a Playwright environment where MSW mocks are not automatically applied unless configured globally.

We need a single source of truth for mock definitions that works for both local story development and CI test runs. Two design options exist: (1) centralize handlers in a shared MSW setup file, or (2) define mocks per story using the addon’s msw parameter. Each approach impacts test isolation, maintenance overhead, and the ability to version mock scenarios across unit tests, end‑to‑end tests, and Storybook stories.

Unresolved decision: how to share and version mock scenarios so that the same mock definitions are used consistently across Storybook, unit tests, and Playwright test‑runner executions, while preventing accidental real network calls in both development and CI.

Specific questions

• What is the recommended pattern for loading MSW handlers in the Storybook test‑runner so that they are automatically applied to all stories?
• Can we expose a shared mock registry that can be imported by both unit tests and Storybook stories, and if so, how should it be structured to support per‑story overrides?
• How can we ensure that production credentials are never sent during Storybook runs, especially when the API base URL is defined via environment variables?