Testenix 0.3.0 makes native execution project-aware instead of assuming that the logical CPU count is always the best worker count.
Highlights
- Adaptive
workers = "auto"selection based on execution units, CPU capacity, duration-history coverage, predicted process-start cost, and makespan. - New
testenix tunecommand (also available astestenix benchmark) for fresh-process, counterbalanced worker measurements. Configuration is changed only with explicit--write, guarded by source fingerprints and configuration-drift checks. - Opt-in
--shard-modulesexecution for eligible modules. Conservative static checks retain normal module affinity when fixtures, global mutation, or import-time lifecycle hazards are detected; enabling sharding remains an explicit trust decision for dynamic behavior. - Source-verified collection manifests via
testenix manifest, allowing unchanged suites to avoid a duplicate collection import. Stale manifests safely fall back to supervised collection. - New synthetic 100/500/1,000/3,000-test matrix tooling and a redaction-safe real-project benchmark harness, with bounded timeout cleanup on Windows and POSIX.
Benchmark context
The existing 3.15× result is a historical Testenix 0.1.0 synthetic baseline: 100,000 no-op tests across 16 modules, four workers, --no-history, on one Apple M4 Pro / CPython 3.11 machine. It is not a Testenix 0.3.0 or real-project result.
No clean Testenix 0.3.0 scaling matrix is published with this release, so Testenix does not claim a universal speedup over pytest. Run testenix tune in your own project and consult the documented benchmark methodology before making a project-specific comparison.
Install
python -m pip install --upgrade testenix==0.3.0Full Changelog: v0.2.1...v0.3.0