Generic typing for TestClient

[singingwolfboy]

I'm using Starlette's TestClient through FastAPI, and I feel like the static typing support could be improved. In particular, I'm in a situation where I'm passing an instance of a TestClient to a testing function using a Pytest fixture, and I want to set a dependency override for the FastAPI app before using the client. Here's the way my code looks:

import pytest
from fastapi import FastAPI
from fastapi.testclient import TestClient
from myapp import make_app
from myapp.config import get_settings, Settings

@pytest.fixture
def app() -> FastAPI:
    return make_app()

@pytest.fixture
def client(app: FastAPI) -> TestClient:
    return TestClient(app)

def test_dev_env(client: TestClient):
    client.app.dependency_overrides[get_settings] = lambda: Settings(environment="dev")
    response = client.get("/example")
    # make assertions here

When I run this code, it works just fine, but when I ask Mypy to typecheck my code, I get the following error:

error: "Callable[[MutableMapping[str, Any], Callable[[], Awaitable[MutableMapping[str, Any]]], Callable[[MutableMapping[str, Any]], Awaitable[None]]], Awaitable[None]]" has no attribute "dependency_overrides"

After looking at the code that defines the TestClient, I can see why: the types are set up to allow any arbitrary ASGI app, but they ignore any further type information. I think it would be better if this class were generic, so that the user could inform the type system about which ASGI implementation they are using. Then I would be able to define the same test with a more specific type, like this:

def test_dev_env(client: TestClient[FastAPI]):
    ...

Which would allow Mypy to typecheck my code and verify that I am using the client.app object correctly. Does this seem like a reasonable use-case?

[singingwolfboy]

I just opened a pull request to demonstrate what I mean.

[adriangb]

Could you also inject your app fixture?

def test_dev_env(client: TestClient, app: FastAPI):
  ...
```

[singingwolfboy]

I absolutely can, but there are two reasons why I don't think that's a good enough solution here.

1. It makes the test code less clear, because it does not demonstrate how the client and app variables are related to each other. Modifying client.app followed by calling client.get() makes it clear that the two steps are related; modifying app following by calling client.get() relies on implicit knowledge that these two different variables are actually related to each other. Especially when you consider that this could be one test in a large test suite, and the developer looking at the code may not know Pytest conventions very well, this is a big deal!
2. Even if I solve this specific problem in this specific way, it still doesn't change the fact that Mypy doesn't understand what's going on inside client.app, and that can cause problems for the developer experience. For example, it means that IDE autocomplete won't work as well as it could.

I provided this specific example to demonstrate why I would like TestClient to be generic. I understand that there are other ways of solving the problem in this example, but my intention is not to get assistance on debugging my test code; my intention is to improve Starlette's test client.

[Kludex]

ASGIApp should be a protocol, that would solve the issue here.