HTTPX-based TestClient?
See original GitHub issueHi folks,
Currently, the TestClient
is built as a subclass of requests.Session
.
What would be thoughts on migrating to HTTPX?
- Is this a good idea at all?
- Should the
TestClient
be built around HTTPX, or should it eventually be replaced by HTTPX and its ASGI support?
As of today, there are definitely blockers to a full migration. An important one is that HTTPX doesn’t support WebSocket yet (see https://github.com/encode/httpx/issues/304), while TestClient
does.
Happy to discuss! cc @tiangolo @gvbgduh @tomchristie
Issue Analytics
- State:
- Created 4 years ago
- Reactions:20
- Comments:14 (12 by maintainers)
Top Results From Across the Web
Testing - FastAPI
Create a TestClient by passing your FastAPI application to it. Create functions with a name that starts with test_ (this is standard pytest...
Read more >Marcelo Trylesinski on Twitter: "WebSocketException merged ...
WebSocketException merged in Starlette. HTTPX based TestClient approved. Today was a great day. 8:33 PM · Sep 5, 2022 ·Twitter Web App.
Read more >Test Client - Starlette
The test client allows you to make requests against your ASGI application, using the httpx library. from starlette.responses import HTMLResponse from ...
Read more >Kludex/starlette-testclient Repository Page - - Ringer
Kludex/starlette-testclient is on Ringer. ... HTTPX based TestClient for Starlette. https://github.com/Kludex/starlette-testclient ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
For those who use FastAPI and would like to use httpx instead of requests for testing, I have stolen and adapted some code from our awesome @tomchristie
I’m pretty sure that’s part of the initial objective, to move to HTTPX instead of Requests.
Given it’s basically the same interface as Requests, I don’t think there would be any problem with it for users/developers.
I’m personally happy with it. 🚀
Of course, after solving the blockers, but I think it’s a good idea. It should also give more flexibility and control on how to do stuff, how to extend, etc.
I guess we should support the
TestClient
, probably as a wrapper, at least for some time, to not break existing implementations, even if the decision was to drop theTestClient
completely to fully move to HTTPX and and mark theTestClient
as deprecated in favor of HTTPX.I also think we should start adding “how to use HTTPX” to docs, as it’s the perfect match for async frameworks when communicating to third parties. But that’s another topic.
@dmontagu you have been helping a looot with FastAPI recently ( 🙇♂️ 👏 ), do you see any obvious drawbacks to this?