gabbi icon indicating copy to clipboard operation
gabbi copied to clipboard

Lazy generation of client (and transport)

Open kajinamit opened this issue 6 months ago • 7 comments

Commit 4d9d3b47e5dc09b7db7a20c2e4b4cf73993a2332 changed when a WSGI app used for intercept is instantiated, and we are no longer able to set up pre-conditions for application using the fixtures hook.

Delay creation of the test client instance (which also instantiate the given WSGI app) to restore the mechanism.

kajinamit avatar Jun 28 '25 17:06 kajinamit

Something like this might work, but isn't the wsgi app getting initialised for every http class, meaning for every single test? I'm not certain that's the case, but it looks that way.

If that's the case, that's probably too expensive for some wsgi apps which might have lots of setup.

If there's some way to store the lazily-created client on the Suite, that might achieve what you're after?

cdent avatar Jun 28 '25 19:06 cdent

If there's some way to store the lazily-created client on the Suite, that might achieve what you're after?

Note that it would need to be the client member of the Http class, not the http class itself, as each test needs to have individual control over the verbose aspect.

cdent avatar Jun 28 '25 20:06 cdent

Yeah, it creates a new client for every intercepted test, meaning it restarts the wsgi app for every test. Somewhere north of 170 times. If we attach the client as a member to the suite it is a more reasonable <50 (which is closer to the number of yaml files).

See if a cleaned up version of the following diff works?

less-lazy.diff.txt

cdent avatar Jun 29 '25 14:06 cdent

It's also at https://github.com/kajinamit/gabbi/pull/1

cdent avatar Jun 29 '25 14:06 cdent

In my PR one thing that will need to be checked for correctness is test suites where requests to "real" hosts are mixed with requests to the intercepted apps.

cdent avatar Jun 29 '25 15:06 cdent

where requests to "real" hosts are mixed with requests to the intercepted apps

It appears to not be working, so the logic probably needs some adjustment.

cdent avatar Jun 29 '25 15:06 cdent

Thinking about this overnight, the code in this patch maintains the same behaviour as >=4.0: Each test has its own transport, thus each test starts its own WSGI app.

As I state above this is probably undesirable. My patch hangs the client on the suite, but then every request uses the WSGITransport meaning any test that is in an intercepted suite that requests an external URL does not work as expected (there's apparently a shortcoming in the existing tests that needs to be fixed as part of addressing this).

When a test URL has no scheme (http or https) then it will get a self.host that is a stringified uuid4. Perhaps we could check for this during the http client request and choose between the intercepted client and a non-intercepted client.

Thoughts?

cdent avatar Jun 30 '25 12:06 cdent