Home / Glossary
The vocabulary of a warm test runner
rpytest lives in the world of collection phases, warm daemons, and pytest internals. If some of the terms on the how-it-works page were new, here they are in plain language.
- Drop-in replacement
- A tool that keeps the same command-line surface, config, and exit codes as the thing it replaces, so existing scripts and CI work unchanged. rpytest is a drop-in replacement for pytest.
- Collection phase
- The step where pytest discovers and imports test modules and builds the list of test node IDs before running anything. On large or plugin-heavy suites, collection can dominate wall clock — rpytest caches it in the daemon.
- Interpreter startup
- The fixed cost of launching a fresh Python interpreter and importing pytest and its plugins on every invocation. rpytest pays this once per session by keeping a warm daemon.
- Warm daemon
- A long-lived background process that keeps the Python interpreter, imported plugins, and collected test inventory resident, so each run is a fast RPC instead of a cold start.
- conftest.py
- A pytest file that provides fixtures and hooks to the tests in its directory tree. Because rpytest hosts real pytest, your conftest.py runs exactly as it does under pytest.
- Fixture
- A pytest construct that sets up and tears down state (a database, a temp dir, a client) around tests. Fixtures run inside the hosted real pytest, with the same scoping behaviour.
- pytest plugin
- A package that extends pytest via its hook system (pytest-django, pytest-cov, hypothesis, …). Plugins load and run in the daemon; those that assume a fresh process per run are the most likely friction.
- IPC
- Inter-process communication. crate rpytest-ipc defines the message types the Rust CLI uses to talk to the Python daemon, turning each invocation into a small RPC.
- Exit code
- The integer a test run returns to the shell to signal pass/fail. rpytest matches pytest exit codes exactly, so CI gates behave identically.
- Cold vs warm run
- A cold run pays interpreter startup, plugin import, and collection from scratch. A warm run reuses the daemon's resident state and skips straight to execution. The first rpytest run is cold; later ones are warm.
- TDD inner loop
- The rapid edit → run tests → read result cycle during test-driven development. rpytest tightens it with --watch and a warm daemon so re-runs feel near-instant.
- Duration-aware load balancing
- When running in parallel (-n auto), rpytest distributes tests across workers based on their observed durations so workers finish at roughly the same time, rather than splitting blindly.