leoschwarz / reqwest_mock Goto Github PK

View Code? Open in Web Editor NEW

16.0 16.0 6.0 89 KB

Provides a mockable wrapper around the reqwest HTTP client for Rust.

License: Apache License 2.0

Rust 100.00%

http reqwest rust

reqwest_mock's Issues

Using a function from request to response to mock

Wondering if you agree that this would be nice, in which case I can try to implement it.

Looking at the StubClient, it seems only able to serve a given static response for given request parameters (URL etc).
I find myself in a somewhat more complex situation where I would like to mock a service which gives a response that depends on the request (e.g. a field from the request body would appear in the response body).

So my suggestion is for ResponseStubber to have a function like

pub fn body_with<B: Into<Body>, F: Fn(Method, Body, HeaderMap) -> B>(self, body: F) -> Self

Or should I create a new client struct (not StubClient) for this?

Disable mocking with a cargo feature

Evaluate whether there is a need to disable mocking with a cargo feature.

The main use case I would see is a crate using reqwest_mock internally (i.e. not exporting the mockability to API users) to test the crate with a cfg(test). In this case removing all mock functionality might remove binary size (removing some dependencies) and depending on the optimizations which are made in reqwest_mock also speed up the final binary.

What would speak against such a feature is that it would obviously make the code base more complicated.

Test all clients

There should be integration tests (inside tests directory) for all clients.

DirectClient (basic test)
DirectClient (full test)
ReplayClient (basic test)
ReplayClient (full test)
MockClient (basic test)
MockClient (full test) -> Maybe this should be postponed until the mock client's API is sort of solid.
GenericClient/Client: This one is a bit more complicated, as we don't want to repeat all the other tests, but there should also be an integration test for this I think.

Versioning of replay files

Store the version number of reqwest_mock in the replay files and only deserialize files with the correct version number.

Evaluate how this check of the version number can be performed using serde before deserializing the whole thing, so that this will be future proof and we don't have to worry about breaking the format in the future that much.

Automatic replay file managment in a specified directory

Design an API that provides a way to specify just a directory and everything will be handled automatically.

Open question:

How would the filename be determined? Obviously since a request could have unlimited data, we should use a hash at least for that, but is it really ok to just use hashes as filenames? How would a user be able to find the right replay file to delete if something has changed?

Write examples

I guess this is mostly work for when the other issues are resolved but still not unimportant either

Example on how to use ReplayClient to unit test a custom client.
GenericClient example
StubClient example.
Using explicit generics over Client.

Implement StubClient

WIP

Integration with the http crate

The http crate provides fundamental http types. In general it might be cool if as much of the API here could be replaced with code from that crate since this would increase interoperability with other crates.

Better compression for replay files

Currently bytes will be written into a json array of numbers, which for larger requests could mean a significant overhead. Either evaluate an alternative to json (like msgpack or something similar) or improve the serialization somehow.

Refactor using ClientBuilder like it was done in reqwest

Think about better names for `Client` and `GenericClient`

I think especially GenericClient might be confusing and ugly in api user's code.

examples dosen't match 0.7.0

example code:

let client2 = ReplayClient::new(RecordingTarget::file("simple.replay"));
    let resp1 = perform_request(&client2, URL);
    let resp2 = perform_request(&client2, URL);
    assert_eq!(resp1, resp2);

ReplayClient need two arguments

async support

The client use reqwest::blocking internally, which as noted in the docs can't be used in async contexts. I've just hit this in palfrey/dawn#32 trying to work with the actix test server, which wants everything to be async.

Read-only mode for ReplayClient

It would be really useful to have a read-only mode for ReplayClient. This means you can do things like write a bunch of responses in local testing, commit them to source control, and then enable read-only mode in CI so it only uses the responses that are already written.

I've used features like this in VCR.py which has a variety of useful "record modes" like this

leoschwarz / reqwest_mock Goto Github PK

reqwest_mock's People

Contributors

Stargazers

Watchers

Forkers

reqwest_mock's Issues

Recommend Projects

Recommend Topics

Recommend Org