-
Notifications
You must be signed in to change notification settings - Fork 247
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
Support matching query params for post
, put
methods.
#130
Conversation
…sts methods. Add a params argument to mock.on{Method} function. Add params to handler array
… in test to find headers.
post
, put
methods.post
, put
methods.
@ctimmerm , can you let me know if anything can be improved or if there is a problem with the PR? Thanks ! |
@ctimmerm Hello Colin, Again, may I get some feedback on this PR ? I'd really like to get this merged. If something is wrong please let me know and I will work on it. Thank you for your time ! |
@ctimmerm @thk2b It'd be great to get this feature in! Usage of params with POST/PUT requests shows up in the Axios docs and I'm sure many developers need this feature to properly filter which requests to mock. Right now my not-so-great-work-around without this feature is to check the params in the reply
Since I have no way to trigger a passThrough within the reply, I need the ability to filter up front as a part of the onPost call with params. |
Thanks, @clockworked247 (and @thk2b).
|
Do you know when this feature will be merged? |
Any news if or when this does get merged? |
any news? it's like 2023 already. |
I'll try to get #387 through and merge with a coworker of mine. I guess it can land within the next two days and then we can release it as v2. |
v2.0.0 is released with support for |
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.