Giters

schemathesis / schemathesis

Supercharge your API testing, catch bugs, and ensure compliance

Home Page:https://schemathesis.readthedocs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[FEATURE] Use `httpx` for the transport layer

devkral opened this issue · comments

commented

Is your feature request related to a problem? Please describe

Currently schemathesis uses requests. This has following drawbacks:

  • no real async/asgi, you need to write boilerplate code
  • the starlette test client switched to httpx, incompatibilities
  • requests development is stalled, so the incompatibilities will increase

I would recommend to migrate away from requests and can recommend httpx as alternative.
There are maybe some other nice libraries out there but httpx has two killer features:

  • calling asgi/wsgi directly, no need for boilerplate. No need for the Starlette TestClient for downloading the schema (uses httpx internally anyway)
  • async. Soon ASGI will be more common and it will become harder to test without async support

@Stranger6667:

Moving all the current transports to httpx will have the extra benefit of dropping starlette_test_client, werkzeug & requests. I hope all of them can be dropped and we can use just different httpx transports.

Also, the Schemathesis test runner will benefit from async execution of requests which will be simpler to implement as it will help with cancellation (i.e. httpbin's drip endpoint can hang schemathesis)

On the implementation side of things, the ASGI transport is async, but the main flow is sync, so we need an adapter to run those requests synchronously.

Such a change will likely happen with the 4.0 release.

commented

and there seems to be a transition to httpx so your code would be more interoperable

commented

everyone has his own library preferences ;). It is just my recommendation.

commented

There is a long-running plan to switch to httpx (specifically in #1718 and previously discussed in some more issues) for multiple reasons, the main one for me is the cancellation in CLI.

While I agree with the reasoning you provided, I feel that this is more like a duplicate of #1718 that suggests providing multiple transports instead of a complete switch (it also will unblock alternative transports that could be something useful for future gRPC support). A complete switch would be backward-incompatible for many users who would be forced to switch to using httpx in their tests and with pluggable transports such a transition would be smoothened.

It is completely fine to switch rapidly for apps, but for a library on which many users rely on, I'd prefer to take a more flexible way.

As a side note, what kind of boilerplate did you mention? I am genuinely interested in reducing the amount of boilerplate, but I'd like to have some actionable inputs and clearly see how httpx will help to avoid it - it will also help me to provide a better API from the Schemathesis side for all users.

commented

Now, I also see that #1718 lacks certain implementation details about the transport layer. I'm going to update it soon

commented

thanks! And sorry for the duplicate

Found another frustrating bug: requests.Session is incompatible with asgi/wsgi

commented

an idea:

you have the method get_requests_kwargs. Check if the class is requests.Session or httpx.Session and transform the arguments accordingly or remove if not supported.

This way httpx Session can be used by default (and the boilerplate code removed) and requests.Session only if explicitly specified (it doesn't supports wsgi/asgi calls anyway as far as I know)