Mocking multiple api’s with jest using jest-api-mock — part 2
Mocking api requests in jest using jest-api-mock; an extensible solution to mock multiple api responses.
You might have already read the previous blog on mocking multiple api’s with jest. It explains the idea behind how i extended jest.mock to mock apis. More on that — here.
I have created an npm package over the approach mentioned in the previous blog. In this write up, i basically try to explain, why you would want to use this package and how its different from jest-fetch-mock which you could use to mock fetch calls.
A central configuration file
One of the important things that jest-api-mock does is, it creates a central configuration file where all your mocks are mapped. If you ever want to change the response for a mock, all you have to do is look at this configuration.
In a large application this would especially come in handy as you could set default responses for all the api’s being used in your app and could customise certain api’s on a case by case basis to cover more use cases.
Handling mock responses at runtime and cleaner test-suites
One of the plus points about jest-mock-api is the fact that you could decide at runtime what response to send based on test-suite. In the above example, the todoHandler and todoPostHandler can receive runtime params when the test-suite begins and you could respond with custom responses.
Consider the below example of a todoHandler implementation.
All implementation to handle different types of responses are in one file, keeping the main testSuite clean, without having to repeat the response again and again for each testFile or testSuite.
The testSuite for the above would look something like below.
Extending the updateParams further
The power of updateParams functionality could be further exploited if you make use of callback functions. In the below gist, we are using a callback function to check if it’s admin or not. With the below approach, your logic to test will be in your test suite only, while the todoHandler will only have default responses based on what your test-suite returns.
Conclusion
- A central place for all configuration and url mapping
- Cleaner test suites
- No need to configure responses for each and every testSuite. Default responses could be configured in your urlMapper or a custom urlHandler function could be implemented for handling further complexity.
- All the mocks will be in one place.
- Mocks can be placed anywhere you want, instead of having to keep them in __mocks__ like jest expects.
- Easier to debug and reason about.
Feedbacks are really appreciated. Do let me know if you feel this could be extended for further use cases.
Npm package link — https://www.npmjs.com/package/jest-api-mock