A test runner you can trust.
Testing starts while the build is still running, with retries, flaky-test detection, re-runs of what failed, cached results and coverage built in.
- to confirm Rune's 285 tests still pass when nothing changed — 8 s without --cached
- 0.26 s
- Cargo's speed running the tests, on a generated 25-crate workspace
- 9×
Testing starts before the build ends.
Test binaries are part of the same build graph as everything else. The first one runs the moment it links, each result prints as soon as it is in, and a live line shows what runs now, how many tests have passed and for how long.
One test binary at a time
As with Cargo, so suites that share a port, a file or a database don't fail at random — while the build goes on. --test-jobs 4 runs binaries side by side when nothing is shared.
The slowest binaries first
Rune remembers how long each test binary ran and builds the ones a run will wait on longest — and the programs their tests start — before the quick ones.
A hung test can't hang CI
With --timeout 10m, a binary that runs longer is stopped and reported as failed, naming the tests that had not finished.
Leftovers don't hang the run
A test that starts a server and forgets it no longer keeps rune test waiting once the test binary exits.
Programs a test starts are ready
A package's binaries and examples are built before its tests run, so CARGO_BIN_EXE_<name> works, as with Cargo.
Cargo's environment
CARGO_MANIFEST_DIR, every CARGO_PKG_*, CARGO_TARGET_TMPDIR and the library paths of build scripts' native libraries.
Everything a CI job asks of a test run.
Reports, retries, timeouts and machine-readable results, without plugins — and -q leaves out everything but the result line and the failures.
rune test # unit, integration and doc testsrune test parse -- --nocapture # a filter, and arguments for the binariesrune test --failed # only what failed last timerune test --retries 2 # passing on a retry: flaky, not failedrune test --junit report.xml # a JUnit reportrune test --timeout 10m # stop a binary that hangsrune test --cached # skip binaries that passed with identical inputsrune test --schedule tests # batches spread over every corerune test --message-format json # one line per finished binary
Fix it, then run just that.
The edit-and-retry loop while fixing a test, without the rest of the suite — and a clear verdict on the tests that only fail sometimes.
Re-run just what failed
rune test --failed builds and runs only the binaries the failed tests are in, and only those tests. Repeated, it narrows down to what is still broken; once nothing is, it runs everything.
Flaky tests, named
--retries 2 runs failed tests again by exact name. One that passes later is reported as flaky — in the summary and the JUnit report — instead of failing the run.
Cached results
--cached skips binaries that passed with identical bytes, fixtures, arguments and environment: 8 s down to 0.26 s on Rune's own suite. Opt-in, for tests that don't touch the network or the clock.
Scheduled across binaries
--schedule tests splits each binary's tests into batches scheduled across all binaries at once, like cargo-nextest: a suite dominated by one large binary finishes sooner.
Coverage, built in.
rune coverage is source-based coverage like cargo-llvm-cov: only the workspace's own crates are instrumented, so dependencies stay shared with ordinary builds — and the instrumented build has a directory of its own, so both stay warm.
file lines functions regionssrc/lib.rs 8/17 47.06 % 2/3 66.67 % 9/19 47.37 % not run: 5, 11-17total 8/17 47.06 % 2/3 66.67 % 9/19 47.37 %✓ 47.06 % of lines covered (8 of 17) · 1 files
Reports as LCOV, JSON, Cobertura or HTML; --fail-under 80 fails the run below a threshold.
Try it on your project.
Nothing to migrate and nothing to undo: your project keeps working with plain cargo.
$ curl -fsSL https://www.runepm.com/install.sh | sh