Method to dynamically set the transport

[adriangb]

Use case: I use httpx as a client within FastAPI apps.
For end-to-end/integration testing, I like to build my mocks as FastAPI apps themselves and attach them as via the app init parameter, instead of patching/mocking httpx calls (although respx is awesome when needed).
However, a problem arises since the initialization of httpx.AsyncClient is happening as part of app startup/setup, and there is no easy way to inject an extra app parameter at that point.

Proposal: add an attatch_app or a more generic set_transport method that can dynamically attach an app.

Example:

# App code
from fastapi import FastAPI
import httpx

app = FastAPI()
app.client = httpx.AsyncClient(base_url="https://httbin.org")


@app.get("/")
async def route():
    return str((await app.client.get("/get")).status_code)

# Test code
from fastapi.testclient import TestClient

httpbin_mock = FastAPI()

@httpbin_mock.get("/get")
def mock_get():
    return "Hi!"


def test():
    with TestClient(app) as client:
        with app.client.attatch_app(httpbin_mock):    # could be a context manager?
            client.get("/")    # returns "Hi!"

[lovelydinosaur]

For end-to-end/integration testing, I like to build my mocks as FastAPI apps themselves and attach them as via the app init parameter, instead of patching/mocking httpx calls (although respx is awesome when needed).

Yup, that makes sense. I'd do something similar too.

However, a problem arises since the initialization of httpx.AsyncClient is happening as part of app startup/setup, and there is no easy way to inject an extra app parameter at that point.

The pattern I'd suggest is configuring the client based on an environment variable. (Part of the "12 Factor Apps" design patterns). Make sure that when you run the tests, then an environment variable such as TESTING is set to "True".

When you're initialising the client, switch between using a live client or using one with a mocked transport, based on the environment variable.

[adriangb]

Thanks for the quick reply!

I think you'd need something like this, right?:

def get_client(testing, **kwargs):  # must choose to use **kwargs or list out all args/types
    if testing:
        from tests.mocks import httpbin_mock  # this import wouldn't resolve in prod
        return httpx.AsyncClient(app=httpbin_mock,  **kwargs)
    return httpx.AsyncClient(**kwargs)

I'm sure this can be cleaned up (this particular implementation is pretty ugly), but in general I feel like having this type of "testing helper code" in production is not great.

But I am by no means a 12 factor expert, so maybe it would help me understand a bit if you can elaborate on what factors you think are applicable (3/config as env vars?) and how that would push towards putting (possibly ugly) testing helper code in prod.

Thanks again for the reply and the excellent lib!

[lovelydinosaur]

Not sure I've the time to go into any great detail, but I can point you at an example, here...

https://github.com/encode/hostedapi/blob/master/source/app.py#L30-L50

It might also be worth asking around on any FastAPI discussion groups or whatever.

[adriangb]

Not sure I've the time to go into any great detail, but I can point you at an example, here...

Totally understand!

https://github.com/encode/hostedapi/blob/master/source/app.py#L30-L50

I didn't know that you had that repo/project, will take a look and keep tabs on it in the future!

It might also be worth asking around on any FastAPI discussion groups or whatever.

Will do. I think I'll also ask in respx (since the goal there is already to mock out httpx stuff).

[lundberg]

I'm not sure that RESPX should handle mocking of the actual HTTPX client features, need to think that through though.

Anyway, I answered your question @adriangb, but with a non-FastAPI solution, but with similar feel, using plain RESPX routes and side effects.

[adriangb]

I think what I'm going to end up using here is dependency injection, be it manually (just passing the transport to an app factory function), via a DI framework or via FastAPIs own DI (although this may require some work to support singletons).

I'll try to post a clean example if I can come up with one.

[lundberg]

Gave this some more thoughts and I think using an app as an alternative RESPX router would be really interesting and quite easy to implement, will give a try @adriangb.

[lundberg]

Managed to get a poc working @adriangb with RESPX and FastAPI as a mock router!

I'll add this feature to RESPX, just need to clean and tidy up the code first, before opening a PR.

[adriangb]

Awesome! It's always great to have options.

[adriangb]

Just a small suggestion: you may want to demo/test against Starlette instead of FastAPI, since FastAPI is based on Starlette anyway.

[lundberg]

Good point

[lundberg]

Managed to get a PR working for RESPX, allowing mocking of responses through any ASGI or WSGI app.

[lundberg]

This PR is now merged and will be part of next RESPX release @adriangb.

[lundberg]

FYI, RESPX version 0.17.1 is now released, including this feature @adriangb.