Home / Use cases / Large suites with heavy plugins
ScaleLarge suites with heavy plugins
Amortise expensive collection and plugin import once per session for suites where collection dominates wall clock.
The problem
On a big suite with a non-trivial plugin graph — pytest-django, pytest-cov, hypothesis, and friends — the collection phase and plugin import can visibly dominate wall clock. Every invocation re-imports the same plugins and re-walks the same test tree before anything runs.
How rpytest solves it
- ▸The daemon imports the suite and its plugins once and caches the collected node IDs, so later invocations skip straight to execution.
- ▸Selectors like -k, -m, node IDs, and --lf filter against the cached inventory instead of re-collecting from disk.
- ▸Config is read in place from pytest.ini, pyproject.toml, tox.ini, or setup.cfg — no migration of your existing settings.
- ▸Run --verify-dropin once to diff collected node IDs, per-test outcomes, and exit codes against pytest and confirm parity before you rely on it.
$ rpytest # first run: collect once $ rpytest -k billing # RPC into warm daemon, no re-collect 1 240 selected, 1 240 passed in 6.2s
- ·Plugins that assume a fresh Python process per invocation, or monkey-patch import machinery, are the most likely friction — the verifier flags them.
- ·Real suites with heavy I/O fixtures see different ratios than the synthetic benchmark; the structural win is removing per-invocation collection.
Questions
+ Will a plugin that holds module-level state break under the daemon?
It can, if the plugin assumes a fresh process each run. That is exactly the class of difference --verify-dropin surfaces — it reports which tests disagree and whether the disagreement is at collection or execution time.
+ Does the daemon notice when I edit a test file?
Watch mode re-runs affected tests on change, and the daemon re-collects when the suite changes. For long-running sessions you can restart it with rpytest --daemon-stop if you want a guaranteed clean import.