Skip to content
rpytest GitHub

← Back home · Compare

rpytest vs pytest-testmon

The run-only-affected-tests plugin

testmon and rpytest attack pytest slowness from opposite ends. testmon runs fewer tests by tracking which tests each code change affects; rpytest runs the same tests but pays interpreter startup and collection once per session instead of once per invocation. They are complementary, not mutually exclusive — you can run testmon-selected tests on a warm rpytest daemon.

Feature rpytest pytest-testmon Advantage
Strategy Eliminate per-invocation startup + collection (warm daemon) Run only tests affected by the change Comparable
When it wins Every run, TDD loops, CI hot paths Huge suite + tiny diff Comparable
Correctness risk Runs the selected suite fully; `--verify-dropin` diffs against pytest Can skip an affected test if dependency tracking is imperfect rpytest
State kept between runs Warm Python daemon (interpreter + collection) .testmondata coverage database Comparable
Startup / collection cost Paid once at daemon start Paid on every invocation (testmon selects, pytest still boots) rpytest
Built-in parallel execution `-n auto`, no plugin None (pairs with pytest-xdist) rpytest
Watch mode for TDD `--watch` built in Pairs with pytest-watch / re-run on change rpytest
Can be combined Yes — run testmon-selected tests on the warm daemon Yes — testmon under any runner Comparable
Verifies equivalence to pytest `--verify-dropin` N/A (it is a pytest plugin) rpytest
Install footprint pip install rpytest pip install pytest-testmon Comparable

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 want every run — full suite, TDD loop, CI hot path — to be fast, not just the runs where little changed
  • You want the interpreter startup and conftest/collection cost paid once per session, not on every invocation
  • You want built-in `-n auto` parallelism and `--watch` without adding plugins
  • You want provable pytest-equivalence via `--verify-dropin` rather than trusting change-detection to pick the right tests

Pick pytest-testmon when

  • Your suite is very large and your typical change touches only a tiny slice of it — running fewer tests beats running all of them faster
  • You are comfortable with the tradeoff that imperfect dependency tracking can occasionally skip a test that should have run
  • You already depend on testmon and pair it with your existing runner
  • You want to select tests by change impact rather than speed up the whole suite

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.