Consider using wsgi_intercept instead of starting an HTTP server?

[andrew-tipton-cgg]

I'm investigating various approaches for using py.test to unit test some code which makes HTTP requests. (It's a class that invokes webhooks in the background.)

I like the approach of pytest-httpbin, because using fixtures can keep the test cases from getting too cluttered with extraneous setup/teardown code. However, I'm not too keen on the idea of spawning an actual HTTP server in the background, because the code under test is already using a known-good HTTP client library.

What about using wsgi_intercept? It basically does what it says on the tin: intercept outgoing HTTP requests and redirect them to an in-process WSGI application. No actual HTTP client or server is involved!

Any reason why this wouldn't work or isn't a good idea? Would you accept a pull request that implemented this feature?

[ml31415]

Yeah, that might be a good option to have. E.g. with running gevent, just spawning some other threads on the side suddenly becomes more of an issue.