← Back home · Compare
rpytest vs pytest
The Python test runner baseline
pytest is the baseline rpytest is wire-compatible with. The comparison isn't "ours is better" — it's "you can keep pytest semantics and drop the startup tax."
| Feature | rpytest | pytest | Advantage |
|---|---|---|---|
| CLI flags | Same as pytest | Reference surface | Comparable |
| conftest.py / fixtures / plugins | Hosted real pytest in daemon | Native | Comparable |
| Config files (pytest.ini, pyproject, tox) | Read in place | Read in place | Comparable |
| Exit codes & JUnit XML | Match pytest exactly | Reference | Comparable |
| Wall clock incl. startup (500-test bench) | 0.32 s (BENCHMARK.md) | 0.63 s (BENCHMARK.md) | rpytest |
| CLI memory footprint | ~5.9 MB (BENCHMARK.md) | ~39.4 MB (BENCHMARK.md) | rpytest |
| Collection cost per invocation | Paid once at daemon start | Paid on every invocation | rpytest |
| Built-in parallel execution | `-n auto`, no plugin | Requires pytest-xdist | rpytest |
| Watch mode for TDD | `--watch` built in | Via pytest-watch / entr | rpytest |
| CI shard split | `--shard N --total-shards M` | Via plugins or manual | rpytest |
| Implementation | Rust CLI + Python daemon | Pure Python | Comparable |
| Ecosystem & plugin maturity | Inherits pytest's | Reference | pytest |
| Drop-in verification | `--verify-dropin` diffs both runs | N/A (it is pytest) | rpytest |
Benchmark numbers cited are from rpytest's BENCHMARK.md on a 500-test synthetic suite (AMD Ryzen 7 5700U, Python 3.12.3, pytest 9.0.2, pytest-xdist 3.8.0). Your suite will differ.
Pick rpytest when
- ▸You run pytest often enough per day that interpreter startup is visible (TDD, watch loops, CI hot paths)
- ▸Your suite spends a non-trivial share of wall clock on collection rather than on the tests themselves
- ▸You want parallel execution without installing and configuring pytest-xdist
- ▸You want a CLI that pays the conftest.py import cost once per session, not per invocation
Pick pytest when
- ▸You run pytest infrequently and the startup cost is irrelevant to your day
- ▸Your suite uses a plugin that the drop-in verifier flags as incompatible
- ▸You need pytest-exact stdout formatting that downstream tooling depends on byte-for-byte
- ▸Your environment can't host a long-lived background process (some sandboxed CI runners)
Want to verify the swap before you commit?
Run rpytest --verify-dropin on your suite. It runs both pytest and rpytest and diffs the collection, results, and exit codes. If anything disagrees, you find out before CI does.