🚀 Features
Section titled “🚀 Features”Parallel suite execution
Section titled “Parallel suite execution”Feb 24, 2026 · @mavam, @codex · #29
Test suites can now execute their members in parallel by specifying mode: parallel in the suite configuration. By default, suites continue to run tests sequentially for stability and predictability.
To enable parallel execution, set mode: parallel in the test.yaml file alongside the suite configuration:
suite: name: my-suite mode: parallelfixtures: - nodeParallel suite execution is useful when tests within a suite are independent and can safely run concurrently. All suite members share the same fixtures and execute within the same fixture lifecycle, while test execution itself happens on separate threads. The suite thread pool is bounded by --jobs, so suite-level concurrency stays within the configured worker budget and does not scale unbounded with suite size.
Suite-level constraints like timeouts, fixture requirements, and capability checks still apply uniformly across all members, whether running sequentially or in parallel.
🐞 Bug Fixes
Section titled “🐞 Bug Fixes”Shell test files default to shell runner
Section titled “Shell test files default to shell runner”Feb 24, 2026 · @mavam, @codex · #30
Shell test files (.sh) now always default to the “shell” runner, even when a directory-level test.yaml file specifies a different runner (for example, runner: tenzir). This makes shell scripts work reliably in mixed-runner directories without requiring explicit runner: frontmatter in each file. Explicit runner: declarations in test file frontmatter still take precedence and can override this behavior if needed.
Fix default fixture options in manual fixture control
Section titled “Fix default fixture options in manual fixture control”Manual fixture control now behaves consistently for fixtures that declare dataclass options.
Previously, starting a fixture with acquire_fixture(...) could fail when no
explicit options were provided, even if the fixture defined defaults.
With this fix, current_options(...) returns default typed options in the
manual fixture-control path, so fixtures started manually and fixtures started
through normal test activation behave the same way.