-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design discussion: support higher-scoped (class/module/session level) fixtures? #89
Comments
Using the same trio loop with different tests is a very slippy slope (typically with the current Adding greenlet to the mix is a whole new layer of complexity, pytest-trio is already far from trivial so this seems like another big red flag. I think the best way to implement higher level fixture is to use them to start a separate trio loop within a thread. |
I was investigating using pytest-trio to write some integration tests, where I have some expensive services to setup, so want to have session scoped fixtures for the services. I also want to collect logs from the services as they run, and sometimes restart those services from the tests. It is definitely less appealing if I need to manage my own loop for anything session scoped, or that interacts with code from the session scoped things. In terms of implementation, it looks like how trio is structured to support guest mode could be used to support suspending and resuming the loop. With the current public API, you could have one long-running trio loop, which is what is exposed to users; then, when running a async test or fixture, iterate the host-loop calls (perhaps using a separate trio loop). This would require at least a little glue to capture the guest calls to It is definitely true that you can't use the current nursery fixture from non-function scoped fixtures; the same is true of pytest's |
I'm unclear on what the danger is in using the same trio loop for both session and module fixtures in addition to just function fixtures. I don't understand why we couldn't have a session-scope nursery, a module-scope nursery under that, then the function-level nursery under that, then automatically cancel the nurseries when the module is complete and at the end of the session, in the same way the function level nursery is already cancelled. Is it somehow possible for an async method to outlive the nursery it was spawned in? |
I wanted to chime in here to emphasize that the lack of support for session/module/class-scoped async fixtures is a serious limitation for us. We're writing unit tests to exercise code accessing a PostgreSQL database using the I know that I might be willing to donate some effort to make session/module/class-scoped async fixtures in |
@jmehnle The basic difficulty is that all of pytest's internal test runner logic is synchronous code, so we can't easily open an event loop "around" the test runner and run tests inside of it, because synchronous functions can't do a blocking call into an enclosing async context. However, we now have two technologies that we didn't have when this issue was first opened, either of which might be able to bridge that gap:
Of these I think guest mode is probably a better fit for pytest, and it also avoids the greenlet dependency. Higher-scoped fixtures require a single Trio run that wraps all tests in their scope. This is incompatible with current popular use of fixtures like To solve your immediate problem, it is probably going to be much much easier to use a synchronous session-level fixture that starts a thread and runs the container from the thread. |
Thanks for the great overview. I will ponder this in the coming weeks. FWIW, and for anyone having a similar problem, I have worked around the limitation by using a synchronous session-scoped fixture that spins up the database container and talks to the database using a synchronous database driver to set up the DB, in deviation from the asynchronous driver we use in application code. This is pretty ugly, and I'd still very much love to get rid of this pile of dirt. |
I'm pretty sure it's possible if we're willing to use greenlet.
Here's a sketch that's missing important details like exception propagation.
Hook pytest_runtest_loop to keep a Trio event loop running in another greenlet for the whole pytest invocation:
Hook fixture setup to run async fixtures in the Trio greenlet:
Hook running-the-test to run async tests in the Trio greenlet (not shown).
The details are decidedly nontrivial, but I don't see any showstoppers... thoughts? Maybe this could totally replace pytest-trio's current strategy, but it's not a win across the board, so I'm imagining it more as an alternative mode.
Benefits:
Drawbacks:
The text was updated successfully, but these errors were encountered: