search

jefflau / jest-fetch-mock

Jest mock for fetch
MIT License
882 stars 116 forks source link

Feature request: always mock by URL #186

Closed pastinepolenta closed 3 years ago

pastinepolenta commented 3 years ago

Scenario This reiterates what is already asked in https://github.com/jefflau/jest-fetch-mock/issues/145 and https://github.com/jefflau/jest-fetch-mock/issues/171 but I would like to elaborate a little. Please close it if you find it a duplicate.

I honestly thought that the all point of this library was to provide a mapping URL -> response so that we can easily emulate some backend API during jest tests. This is not really the case, cause all the mock options either unmock previously mocked paths, or mock "in bulk" but without the URL condition.

Perhaps there is a good reason for what I consider a huge missing point for this library, please explain if that is the case.

Request Add something like mockAlwaysIf, mockManyIf, mockManyByUrl... that would allow to map many URL (regexp) to their own mocked response regardless of the test and the order of execution and without un-mocking anything previously mocked.

Reason This IMHO is closer to how a real app behaves, the same API always gives the same response, no matter the call order. This is especially useful when multiple tests require common "setup" operations (as described in #171) and re-mocking in order is a duplication and I would argue is not even a relevant part of the test and should be done at "global setup" level.

This also would ease scenarios where the API call order is not clearly defined, and is not even relevant (as long as for a given API the response is deterministic)

The workaround proposed in #145 doesn't really cut it when you want to mock the entire set of APIs, which can be many in a fairly complex application.

yinzara commented 3 years ago

I think you made assumptions about how the library works that aren't necessarily made by everyone who uses it (and certainly not if you had read the readme). While you may disagree, we can't redesign the entirety of the library to make it less confusing to you. The suggestions you're making would competed change how the library functions.

I'm also not sure how the suggestion in #145 doesn't solve the issue presented.

Can you provide a use case where that solution wouldn't work?

pastinepolenta commented 3 years ago

That solution works, with "doesn't really cut it" I meant like it would require a huge regexp and long serie of if/else that I was hoping to abstract away. I am closing this issue then. For who's interested in this particular feature I found another library "fetch-mock-jest"