v5 proposals

[wheresrhys]

Handling unmatched requests

Currently configured by passing greed: 'good'|'bad'|false in to mock(). Inadvertently, this persists even after restore() is called, which is a bug, but not necessarily worse behaviour than intended. What might be better is either

• a global config option, documented as such
• better warnings and errors, documentation pointing users towards putting lots of catch-all mocks in a beforeEach, and deprecating the greed option. Less magic, smaller API.
  • perhaps accept a '*' matcher, or maybe a .catch() method to define how unmatched calls are handled

Global config

Setting things such as

• How much processing to apply to the mock response (e.g. sendAsJson)

Accept a Response object as the response

Could also be worth exposing the response creator as a utility

Major API change

Having method as an optional second parameter makes modifying the API trickier

.the API could change to mock(matcher, response, options), with shorthands of get(), post() etc. mockOnce(), getOnce() etc would also be nice (see below)

Other things to consider

• Configure number of times a response can be matched - see https://github.com/wheresrhys/fetch-mock/compare/times for failing tests
• Possibly change/augment the behaviour of call matching Add filterCalls(), testCalls() #83
• remove reMock. restore/reset should return instance of fetch-mock so they are chainable
• accept an array of arrays to a single call of fetchMock?? (not so useful now is chainable .mock(a, b).mock(c,d) vs .mock([[a,b], [c,d]]))... deprecate mocking arrays???

[shofel]

• Yeah, greed: 'good'|'bad'|false is confusing a lot. Default matchers like mockAnyResponse look as a better solution
• Call matchers could be of two types: string or RegExp, with intuitive outcomes

[wheresrhys]

with intuitive outcomes

GIven

fetchMock
    .mock('http://thing.com', 200)
    .mock(/.*/, 404)
fetch('http://thing.com') // 200

any thoughts on whether fetchMock.called(/.*/) should be true or false. The argument for true is technically the url does match. The argument for false is that the rule defined for /.*/ is not the one used to construct the response

[shofel]

I get your question.
As for me, there should be two methods to check expectations:

• 'the url has been requested' (string|RegExp --> Boolean)
• 'the handler has been executed'. That is, the rule has been used to construct at least one response (handlerId --> Boolean)

[wheresrhys]

#110