Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback wanted: Syntactic sugar for naming mocks #460

Open
wheresrhys opened this issue Oct 27, 2019 · 2 comments · May be fixed by #570
Open

Feedback wanted: Syntactic sugar for naming mocks #460

wheresrhys opened this issue Oct 27, 2019 · 2 comments · May be fixed by #570

Comments

@wheresrhys
Copy link
Owner

wheresrhys commented Oct 27, 2019

For advanced matching it's beneficial - for determinism and clarity - to add an explicit name to a route via the options parameter:

fetchMock
  .mock(matcherFunc, 200, {name: 'test1'})
  .mock(matcherFunc2, 200, {name: 'test2'})

I've never liked this api, but thankfully never have to use it

Syntactic sugar for this would be to add a .name() method which sets the name of the last added route

fetchMock
  .mock(matcherFunc, 200).name('test1')
  .mock(matcherFunc2, 200).name('test2')

Or alternatively, an ES Proxy could be used to support behaviour like the following

fetchMock
  .test1.mock(matcherFunc, 200)
  .test2.mock(matcherFunc2, 200)

Final idea, support switching fetch-mock into 'name first' mode (this could also be via setting a config property):

fetchMock.expectRouteNames()
  .mock('test1', matcherFunc, 200)
  .mock('test2', matcherFunc2, 200)

Leaving this issue here for feedback

@wheresrhys
Copy link
Owner Author

wheresrhys commented May 9, 2020

Final proposal:

fetchMock
  .mock(matcherFunc, 200)
  .mock(matcherFunc2, 200).$mock2

fetchMock.called('mock2') // gets the calls actually handled by matcherFunc
fetchMock.called(matcherFunc2) // gets the calls that matcherFunc matches

With the easier naming the expectation is that its use for tricky cases like this will become more widespread, and can drop the annoying use of matchers as identifier, and completely rethinnk the inspection methods

@wheresrhys
Copy link
Owner Author

Or possibly

fetchMock.mock(matcher, response, name)

duck-typing

fetchMock.mock(object, name) // expect object to have a response property

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant