Running tests¶
Basic usage¶
Start the default watch loop (press q or Ctrl-C to exit):
Run all tests in your project:
Or run once without installing:
Specifying paths¶
Pass one or more file or directory paths to restrict which tests are collected:
file:line syntax¶
Jump to a specific test by pointing at the line where it's defined:
Tryke runs the test whose definition spans that line. This is especially useful from editor integrations that can resolve the cursor position.
Collecting without running¶
Use --collect-only to list discovered tests without executing them:
This is useful for verifying filtering expressions or checking that Tryke sees your tests.
Stopping on failure¶
Stop after the first failure with -x / --fail-fast:
Stop after N failures with --maxfail:
Parallel execution¶
Tryke runs tests in parallel by default. The worker count defaults to min(test_count, cpu_count). Override with -j / --workers:
Distribution mode¶
By default, each test is its own work unit and can run on any worker (--dist test). Use --dist to control how tests are partitioned across workers:
tryke test --dist file # All tests from a file go to one worker
tryke test --dist group # Tests within a describe() group go to one worker
tryke test --dist test # Each test is independent (default)
file mode is useful when tests share module-level state. group mode balances between parallelism and isolation within describe blocks.
See concurrency for details on the worker pool model.
Project root¶
By default Tryke uses the current directory as the project root. Override with --root:
The root determines where Tryke looks for pyproject.toml, test files, and the import graph.
Filtering¶
See the filtering guide for -k expressions, -m tag filters, and how to combine them.
Reporter format¶
Choose an output format with --reporter:
See the reporters guide for all available formats.
Connecting to a server¶
If you have a tryke server running, connect to it for faster runs:
The server keeps Python workers warm between file changes and caches test discovery, so subsequent runs skip startup overhead. When a watched file changes, the workers are restarted (so the new code loads in a fresh interpreter) and immediately re-warmed in parallel.