mock-requests VS msw

I wrote mock-requests before MSW came out. It was, to my knowledge, the first dev-friendly mocking library out there that didn't involve setting up a separate server yet still allowed dynamic responses. Since MSW came out, I still think mock-requests has a better and simpler API but MSW allows you to see the network request in the browser's dev tools which is super nice IMO.

I'd mock the network responses from the source. Others already mentioned MSW, but I personally like mock-requests better. I don't need to use a complex config nor chained methods, I still get dynamic responses based on request payload, and I can mock the entire app's requests in a single config object (harking back to not needing complex configuration logic or chained methods).

The companies I worked at were using mock-requests to help them with this and it greatly simplified their testing environment. A single call in a test-setup file meant all network calls for all flows were suddenly mocked and accessible for both unit testing and development when servers were down. I'd highly recommend checking it out!

Feel free to check out the in-depth ReadMe, install, see the JSDoc, source code, or check out the React demo.

We’re going to use Mock Service Worker (MSW) for mocking network requests in our integration tests and in the app during development.

However, I discovered a great combination that transformed my API call testing in TypeScript: Vitest and Mock Service Worker (MSW). Their well-crafted design makes them incredibly easy to use, enhancing the overall testing experience.

While mocks are effective, they require modifying the component's internal logic or mocking global functions like fetch. This can become cumbersome for complex components with numerous API interactions. Here's where MSW shines.

> For those wondering what the use case is, you must not have tried it. It does take work to set up (with each version that's less), but it can be very nice to test in isolation esp in cases where a component is under a login, the 4th page of a 10 page form, etc. Also obviously if you're working on a component library that ships without an app, Storybook can be your development and/or demo app.

I have worked with storybook extensively over the past couple of years and my team is moving away from it in favour of MSW (https://mswjs.io).

For "4th page of a 10 page form" during the development there's hot reloading which is really stable nowadays and haven't failed me, although I understand that some setups are old and it might be easier to configure Storybook than good hot reloading.

I'm not entirely sure about the testing part of it and I'd be grateful if you could elaborate. I haven't felt the need for some special setup with SB because for unit tests, I can test a deeply nested component separately. For E2E tests, I usually test the whole form.

I agree on the component library part, this is probably the only use case where Storybook is 100% justified, but I'm unconvinced about the

Additionally, thank you to all our community launch partners across the frontend ecosystem for helping us bring Storybook 8 to the world! Thanks to Chromatic, Figma, ViteConf, Omlet, DivRiots, story.to.design, StackBlitz, UXpin, Nx, Mock Service Worker, Anima, Zeplin, zeroheight, kickstartDS, and Kendo UI.

similar with msw.js, but fully automated

they could be network mocks (use msw)

With orval, we can also integrate the API client in our unit tests. Orval provides first class support for mocking through the (Mock Service Worker)[https://mswjs.io/] library, and it can automatically generate the MSW handlers for testing server.

Consider a hypothetical scenario where data from a list of companies within an ERP needs to be retrieved. As a personal recommendation, leverage tools like MSW for top-level mocks, which can significantly enhance the testing process.