Feature: mocking as a feature of the library

[simonw]

I've been using https://colin-b.github.io/pytest_httpx/ to mock HTTPX in my tests and it works pretty well - but from reading through the source code it looks like will need to be kept up-to-date with changes to HTTPX internals in the future.

This made me think: should mocking be a supported feature of the HTTPX library itself?

Normally I wouldn't suggest this, but due to the way HTTPX is architectude - in particular the ASGI and WSGI integration - I wonder if this might be a library that could be extended to support mocking as a baked-in-feature without too much additional overhead.

Almost every project I write that uses HTTPX needs to mock it at some point in order to write tests. It strikes me that there's a cultural opportunity here to help encourage best practices by promoting a recommended way to write tests for code that makes HTTPX calls to external URLs.

It's probably unnecessary feature creep though.

[florimondmanca]

There's actually some discussion around this already, mainly in the form of a baked-in MockTransport… #1303

import httpx

def handler(request: httpx.Request) -> httpx.Response:
    return httpx.Response(200, json={"hello": "world"})

client = httpx.Client(transport=httpx.MockTransport(handler))

This would work great for cases where users commit to a "dependency injection" style. They'd be able to accept a client as a parameter to be swapped for another one. For example:

class Service:
    def __init__(self, ..., client: httpx.Client):
        ...
        self._client = client

Then in tests:

import httpx

def test_service():
    def handler(request):
        ...

    client = httpx.Client(transport=httpx.MockTransport(handler))
    service = Service(..., client=client)
    ...

But then again, it's also very common that users may not follow dependency injection, and prefer (or have to use) monkeypatching. httpx.MockTransport might still be helpful there, eg by patching WrapperObject attributes or methods.

I'm not sure we'd want to support monkeypatching use cases, though. In general I find this testing style to be fuzzier. Besides there are probably several monkeypatching libraries out there, and we definitely don't want to have to integrate with them all and feed feature creep that way.

So I think "some support for mocking" -- yes, that would be an upcoming httpx.MockTransport(). But right now I don't see us providing much more than that (and that might already be a great addition!).

[florimondmanca]

@simonw I'll go ahead and close this tentatively since we're already tracking a bit of this enhancement through #1303, but we can obviously continue discussions! Any case, absolutely onboard with the idea of having something built-in for mocking. :-)