Support matching query params for post
, put
methods.
#130
+5,311
−33
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR closes #88 and #129.
Currently, it is possible to expect query params for
GET
, or a specific body forPOST
, but it is impossible to expect specific query params and a specific body.To solve this, I added a fourth argument to
MockAdapter.prototype[methodName]
(ie.onPost
,onGet
), which corresponds to the expected query parameters for the request. This allows matching both a body and parameters for methods that have a body (PUT
,POST
, ...).This is entirely backwards compatible, meaning that we can still match the params for
GET
,DELETE
, etc... by specifying the expected params as the second argument (in place of the expected body as forPUT
andPOST
methods). Overall, this PR does not affect the behaviour of the current public api, since it only adds an argument.This test case demonstrates the new behaviour:
Implementing this required adding the expected request parameters to the
handler
array. All indexes throughout the source were incremented as needed. Then, we check that the params do match inutils.findHandler
.I added several new test cases.
I also modified some tests involving matching params, where the expected params were passed inside the
params
key of an object. This was not required, and I'm not sure why the tests passed in the first place. See this commit.