add a http_client::HttpClient implementation for tide::Server

[jbr]

In order to facilitate testing, it is convenient for tide::Server to implement http_client::HttpClient. This allows surf to be used for testing, with only the following shim:

#[cfg(test)]
mod tests {
    use super::*;

    pub fn test_client<State>(server: Server<State>) -> Client
    where
        State: Debug + Unpin + Sync + Send + Clone + 'static,
    {
        let mut client = Client::with_http_client(Arc::new(server));
        client.set_base_url(Url::parse("http://example.com/").unwrap());
        client
    }

    #[async_std::test]
    async fn test() -> tide::Result<()> {
        let app = build_app().await;
        let body = test_client(app).get("/").recv_string().await?;
        Ok(())
    }
}

If http-rs/surf#229 is merged, this would allow:

let app = tide::new();
use surf::ClientExt;
app.get("http://example.com/").recv_string()?;

this is tested by using it throughout the tide testing suite as the basis for test_utils::ServerTesting

Drawbacks/Limitations

This adds a dependency on http-client, but that should be pretty lightweight without default features.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[yoshuawuyts]

This PR is fantastic and absolutely something we should do. I'm very much sold on the end-user API this provides, and I think it'll make Tide's testing workflow second to none.

[yoshuawuyts]

Also cc/ @LukeMathWalker; author of wiremock -- curious to get your input on this!

[jbr]

I've been thinking a bit more about this, and if there's hesitation about the surf PR, we could achieve the same api by just publishing a tide trait behind a testing feature or published in a very small http-rs/tide-testing crate

[Fishrock123]

This seems fine to me, pending the Surf PR, which should probably be finalized first.

[Fishrock123]

Suggested change

	http-client = {version = "4.0.0", default-features = false }
	http-client = { version = "4.0.0", default-features = false }

[jbr]

This PR doesn't depend on the surf PR at all, and in fact we'll want another tide PR to use the surf pr instead of the test_utils::TestingExt trait (which is currently used in this pr, in order to make them independent)

[LukeMathWalker]

This looks really cool 😁

As a web framework user, it's awesome to have a high-level API to interact with an app instance.
Generally speaking though, I prefer to have black-box API tests that actually hit the network. It would be cool to have an app.spawn() method that launches the app in the background and returns me its address to perform HTTP calls.
You could then build on top of it (and have this very same API) by providing an app.client() which spawns an app in the background and returns me a HttpClient instance whose base uri has already been set to match the one from the application.

[Fishrock123]

After looking again I agree in http-rs/surf#229 (comment) that the Surf PR is in no way fundamental.

[jbr]

@yoshuawuyts @Fishrock123 I revisited this PR and scaled it back. The only public change as of the latest commit is the addition of the HttpClient impl for tide::Server, which hopefully will make it less controversial. We can iron out the rest of the details in further PRs, but this will at least allow applications to build their own testing extensions along the lines of test_utils::ServerTestingExt

[jbr]

Merging this because of previous approvals and minimal public api (just an impl, no exports)