Conversation
|
Nice! 😁 |
|
Should all tests also be run with the |
|
Any idea about the best way to factorize code between |
No, that would be too huge of a PR (but also, I don't think we should do it). You just need to test the client itself. |
If we can parameterize tests so that they use both
The thing is that we don't get enough code coverage for I checked that it was the same for The other tests bring full code coverage. Factorizing code between |
|
I was thinking about mixin classes that the test client and the async test client would use, but I'm not sure it's worth it. It would make the code more DRY, but not that much and at the cost of more complexity. Maybe the async test client should live in a separate |
|
Hmm it looks like https://github.com/vinissimus/async-asgi-testclient is just what I needed. |
|
|
||
| @pytest.fixture | ||
| def async_test_client_factory() -> AsyncTestClientFactory: | ||
| return functools.partial( |
There was a problem hiding this comment.
This partial is redundant (and probably the whole fixture too)
Summary
This PR adds
AsyncTestClient, an async equivalent of TestClient. TheTestClientruns in a background thread in order to let the application run in the main thread, while theAsyncTestClientruns in a background task in the same thread as the application.Currently,
AsyncTestClientis almost a duplication ofTestClient, with the replacement of the BlockingPortal with a TaskGroup. I'm not sure if/how some code could be shared.See #2935.
Checklist