You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 10, 2022. It is now read-only.
While it should probably be good practice to separate the path from the query parameter, I think that the mock service should still consider the interaction as matching in this case in order to avoid confusion on the user's end. This seems especially important when employing the more concise syntax
where a separate object is not required to specify the request.
If making the mock service more flexible in this regards is not an option, then I'd suggest to at least improve the error message because the current one makes it fairly hard to see what the problem is.
The text was updated successfully, but these errors were encountered:
+1 for improving at least the error handling on this.
The error we get is pretty unhelpful
FAILED
Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
or sometimes
Missing requests:
GET /resource?query=param
Unexpected requests:
GET /resource?query=param
Yup, that's pretty unhelpful. The mock service should provide an error message or accept the query all in one. I'll raise an issue in the mock service project.
Setting up an interaction using a
withRequest
component as inleads to a No matching interaction found for GET /resource?query=param error on the mock service end.
However, if I split out the query parameter into a dedicated
query
property as inthe interaction is matched successfully.
While it should probably be good practice to separate the path from the query parameter, I think that the mock service should still consider the interaction as matching in this case in order to avoid confusion on the user's end. This seems especially important when employing the more concise syntax
where a separate object is not required to specify the request.
If making the mock service more flexible in this regards is not an option, then I'd suggest to at least improve the error message because the current one makes it fairly hard to see what the problem is.
The text was updated successfully, but these errors were encountered: