test: expand integration coverage for CLI flags and orchestration

[MatthewMckee4]

Summary

This PR closes a set of coverage gaps in the crates/karva/tests/it integration suite for CLI flags, orchestration behaviours, discovery edge cases, and configuration precedence that were either completely untested or only had a single happy-path assertion. It adds 32 new snapshot tests, all using inline snapshots and command_no_parallel() for determinism, and is intentionally scoped to areas not owned by the parallel fixtures/tags/snapshots/filterset coverage effort.

What is now covered

Several CLI flags and their argument-parsing errors had no direct tests. The new tests in crates/karva/tests/it/basic.rs cover --color never and the --color rainbow clap rejection, --no-cache, --no-progress (both with a passing suite and with a failure so that we can assert diagnostics still print), --retry 0 (which turns out to be a no-op rather than an error), --retry N against a test that always fails so retries exhaust, and the --max-fail=0 rejection from the NonZeroU32 type. The CLI parsing-error paths for --num-workers abc, --durations abc, --test-prefix with no value, karva testx (the clap "did you mean test" suggestion), running karva with no subcommand, and pointing karva test at a nonexistent path all now have snapshot tests.

The interactions between --fail-fast, --no-fail-fast, and --max-fail only had isolated tests. Three new tests pin the precedence rules: --fail-fast --no-fail-fast uses clap's overrides_with so the later flag wins, --no-fail-fast --fail-fast stops after the first failure, and --max-fail=N beats --no-fail-fast regardless of order (documented in the SubTestCommand::into_options comment). There is also a new test showing that --num-workers 1 matches the --no-parallel output exactly, and another showing that --dry-run --num-workers 4 still only collects without spawning workers.

The --last-failed flag only had a happy-path test. last_failed.rs now asserts that --last-failed --dry-run ignores last-failed and prints every test (a subtle behaviour worth pinning), --last-failed -E test(~fail_a) intersects the last-failed set with the filter, --last-failed --max-fail=1 stops scheduling after one failure in the rerun, and adding a brand new failing test after a run does not cause --last-failed to pick it up.

For configuration, configuration/mod.rs now covers the KARVA_CONFIG_FILE environment variable (there was no test for it at all), confirms that --config-file wins when both env and CLI are set, and pins that a karva.toml at the project root is still discovered when karva test is invoked from a subdirectory.

The new discovery/edge_cases.rs module fills a handful of discovery holes. It asserts that __pycache__ directories and stray .pyc files are ignored by discovery, that a package with __init__.py sits next to a standalone test_*.py without either breaking the other, that .gitignore excludes directories by default and that --no-ignore restores them, that a Python file containing only helpers (no test functions) is silently ignored, and that empty subdirectories alongside real test files cause no problems.

Follow-ups

While probing the real behaviour to write these tests, a few surprising things turned up that I deliberately did not fix:

karva test --num-workers 0 panics with index out of bounds: the len is 0 but the index is 0 at crates/karva_runner/src/partition.rs:176. It should almost certainly be rejected by clap with a minimum value of 1, or short-circuited at the orchestration layer. No test is pinned for this because the panic output is noisy and the crash is unambiguously a bug.

karva test --dry-run --last-failed ignores --last-failed entirely and prints every discovered test, even after a previous run with known failures. I pinned this as observed behaviour in last_failed_with_dry_run_shows_all_tests but it is worth deciding whether dry-run should respect the last-failed filter so that users can preview exactly what a rerun would execute.

--no-cache is documented as "Disable reading the karva cache for test duration history," and indeed .karva_cache/run-* directories are still written after a --no-cache run. The flag name reads like it disables the cache entirely, which is not what happens. The new test_no_cache_flag only pins that the run succeeds and does not attempt to assert cache-side effects either way.

Test Plan

• just test (856 tests, all passing)
• uvx prek run -a (all hooks passing)

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 1 untouched benchmark

---

_{Comparing test/cli-coverage (4ae60d7) with main (c05b0d3)}

[MatthewMckee4]

Superseded by #670