Add tests for ease

[mre]

For testing an API client which uses ease, I'd like to mock a server response with some predefined JSON data. For example, each request to http://example.com/endpoint would return

{
"key": "value"
}

I could then use this response in my assertions.

Now, one way to achieve this would be to expose hyper's Request::with_connector(method, url, &connector) in ease.

The connector would then be a mock and could return the "fake" response on every request.
Here is some sample unit test from within hyper which uses this mechanism.

As you can see this unit test is currently commented out, so I'm not sure if the behavior has changed and if this is still possible. Nevertheless it would be awesome to be able to test libraries that use ease - and probably ease itself. I would be very happy for any suggestions on how to achieve this.

[SimonTeixidor]

I think that for testing, it makes sense to separate the request logic from the logic that processes responses. That is, to have a function make_request() -> Result<Response, Error>, and then a function request_to_my_type(&r: Response) -> MyType, or an implementation of Into, or whatever. If the HTTP headers are not relevant for your conversion, it might also make sense to send only the body as a string, instead of the Response object, to the conversion function.

I suggest against unit testing for the functions that actually do the request. Instead, I would test those functions by actually running a server locally for the test. That way, you can check that you have gotten the URLs right and so on.

Does this sound reasonable to you? If so, we could just add some helper functions to create mock responses.

[mre]

Thanks for your input @simonpersson 😃

Yes, starting a test webserver is a quick and simple way to test that the whole request-response cycle works.
When I looked into testing with Rust, I found mockito which also starts a local server for the tests. One thing I've noticed was that there were false positives: A test would sometimes fail because of the server not starting/stopping and not because of my code. While I think we could make this work for most cases, there's still a chance of flaky tests due to real I/O access.
Additionally there might be cases where we don't have permission to spawn a the test server. I'm thinking about some CI environments for example.

As in my case I just wanted some lightweight unit tests where I could simply have some mock response JSON string and see if my internal type conversion and error handling works. Something like hyper does internally or yup-hyper-mock.

In the end we might want to have both, integration and unit tests. Most importantly we both agree that we want a simple and straightforward way to test things... with ease. 😉