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
First of all, thank you for bringing this wonderful package to life.
Now, there's one use case that I don't currently see covered - a way to have something custom "in-between" the API and the network, something that could, for instance:
Record a response in some predefined local storage in addition to returning it, and then replay the response for any request that is identical. This could be used to build something like python's betamax package.
Provide ways to simulate the responses in some other way, maybe by defining one's own "replacement" response-generating callbacks.
Provide ways to inspect the request(s), in addition to 1 and/or 2.
Such functionality could be useful if it could happen invisibly to the calling code, so that one could reproducibly test client code that is performing HTTP requests with real response data, but without actually talking to the network.
With the request package this can be achieved by using the parametrized API, where a requester can be swapped in by the with-requester form. I'm relying on this to test with recorded responses in my little (newbie) racket project.
So this is my humble feature suggestion, although I'm not sure if I'm missing something obvious that would make all of this unnecessary to achieve the described goals.
The text was updated successfully, but these errors were encountered:
yurkobb
changed the title
Possiblity: simulated / replayed requests for testing client code
Possibility: simulated / replayed requests for testing client code
Jun 16, 2020
Thanks! I think it would be useful to provide hooks so that something like what you describe can be built on top of the library, but I'll have to think about how to do it.
First of all, thank you for bringing this wonderful package to life.
Now, there's one use case that I don't currently see covered - a way to have something custom "in-between" the API and the network, something that could, for instance:
Such functionality could be useful if it could happen invisibly to the calling code, so that one could reproducibly test client code that is performing HTTP requests with real response data, but without actually talking to the network.
With the request package this can be achieved by using the parametrized API, where a requester can be swapped in by the
with-requester
form. I'm relying on this to test with recorded responses in my little (newbie) racket project.So this is my humble feature suggestion, although I'm not sure if I'm missing something obvious that would make all of this unnecessary to achieve the described goals.
The text was updated successfully, but these errors were encountered: