Skip to content

Testenix 0.3.0 — Adaptive scheduling and trustworthy benchmarks

Latest

Choose a tag to compare

@polishdataengineer polishdataengineer released this 21 Jul 14:50
a1f30ab

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 tune command (also available as testenix 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-modules execution 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.0

Full Changelog: v0.2.1...v0.3.0