Local test server

[yeraydiazdiaz]

Our test suite performs real internet connections. This has worked well for us since it gives us full confidence that httpcore works in real circumstances. However it has some drawbacks:

1. Requires an internet connection,
2. It's slower than a local only setup,
3. Lack of control on the server and thus reduced number of scenarios we can cover on our tests.

In HTTPX we use a local test server based on Uvicorn which has worked well, the only drawback that I'm aware it's the lack of HTTP/2 support.

Should we go for the same approach here?

Related #108

[florimondmanca]

I raised the same concern some time ago on our Gitter channel. I’d also like to move to a local server setup but I've seen some push back - the main benefit of these live server tests being that indeed we test against some random live HTTP/1.1 / HTTP/2 implementation.

It’s a valid point but for me there is also real value in being able to run tests fast and offline. Not against having E2E tests against a live server out there, but we could reduce their number (or not?) and at least separate them from the rest and skip them in case we detect we’re offline. An @pytest.mark.e2e kind of thing.

I also 100% agree that E2E tests only greatly reduces our ability and ease of testing against weird edge cases (though it’s not incompatible - we can definitely just decide to add more integration tests eg against Hypercorn with various configs).

[tomchristie]

Totally up for having a hypercorn based approach for us here. It actually aligns much nicer that uvicorn does, given its nice focus on h11 and h2, and support for different async worker types.

One possible awkwardness might be if hypercorn supports a different range of Python versions to us, but otherwise I don't have any problem whatsoever with us preferring it over uvicorn.