An Interest In:
Web News this Week
- April 26, 2024
- April 25, 2024
- April 24, 2024
- April 23, 2024
- April 22, 2024
- April 21, 2024
- April 20, 2024
Developing with msw
This post is a brief write-up about how Mock Service Worker
radically improved testing experience and -surprisingly- overall development flow on a couple frontend projects I recently worked on.
Testing: mock API to support test
I initially chose Mock Service Worker
just as a Fetch mock replacement, for the only reason that it intercepts network requests at the network layer enabling mocking any requests including Axios's XMLHttpRequest
ones.
msw
approach favor building API mocks in a centralized way so that all tests run against the same set of mocks. (Still, any test can extend msw
mock handlers on the fly, when strictly necessary).
As the projects have scaled, msw
mocks ended up simplistically replicating most of the consumed API. This opened to...
Development: using the same mocks
Since msw
handlers replicate most of API dependencies, I could run the same mocks used by tests in the browser to run the development environment. For free.
Running tests and development environment with the same mocks turned out to be a huge improvement for both testing and development.
Debugging tests
Broken tests could be debugged more easily be replicating the testing scenario in the browser. Same mocks means same application state between tests and browser.
Decouple local development from API
Developing in the browser using local mocks resulted in a faster and more flexible development flow.
Local mocks take almost no time to load but the keep the exact same async flow of real API responses.
Local mocks are easy to extend or change, therefore replicating a new API scenario is trivial.
I ended up using local mocks most of my development time and contacting the actual API in very rare cases.
Storybook
In case you used Storybook, msw
integrates seamlessy with it, too.
MSW inspector: asserting against mocked requests
msw
encourages an end-to-end testing approach, decoupled from code's implementation details which I also recommend:
Instead of asserting that a request was made, or had the correct data, test how your application reacted to that request.
Even though, I sometimes found it necessary to assert against a specific request sent. Like ensuring a post/put
request is sent with proper payload.
For this reason msw
provide a way to listen to intercepted requests.
msw-inspector
is a tiny utility I wrote to inspect msw
intercepted requests and let any testing framework asserting against them.
expect(mswInspector.getRequests('http://my.url/path')).toHaveBeenCalledWith({ method: 'POST', headers: { 'my-header': 'value', }, body: { 'my-body': 'value', }, query: { 'my-query': 'value',});
Original Link: https://dev.to/toomuchdesign/developing-with-msw-3a6l
Dev To
An online community for sharing and discovering great ideas, having debates, and making friendsMore About this Source Visit Dev To