test: add unit tests for metadata, cache, project, and logging data paths

[MatthewMckee4]

Summary

This PR adds targeted unit tests to the pure-data crates where filesystem and process state are irrelevant. Integration tests still cover end-to-end behavior, but several classes of regressions (config merge precedence, cache pruning order, duration formatting boundaries, path resolution on unusual inputs) are hard to exercise from the CLI, so these unit tests pin them down at the source.

karva_metadata

crates/karva_metadata/src/options.rs previously had no unit tests for the TOML parser, Combine derive, or the fail_fast / max_fail precedence added in #666. The new tests parse a nested [test] / [terminal] / [src] document and walk through the resulting ProjectSettings, and they assert that an unknown key or an unknown top-level section is rejected (the struct uses deny_unknown_fields, so a future accidental removal would silently accept garbage config). A dedicated test confirms that to_settings treats fail_fast = true as max_fail = 1, that fail_fast = false is unlimited, and — importantly — that an explicit max_fail wins when both are set:

let options = TestOptions {
    fail_fast: Some(true),
    max_fail: Some(MaxFail::from(NonZeroU32::new(5).expect("non-zero"))),
    ..TestOptions::default()
};
assert_eq!(options.to_settings().max_fail, MaxFail::from_count(5));

There is also a regression test for max-fail = 0: because MaxFail wraps NonZeroU32, the deserializer must reject the literal zero rather than silently collapsing to unlimited. Finally there are Combine tests that assert CLI values win over config file values for scalars and that Vec-typed fields like SrcOptions::include concatenate file entries before CLI entries (so CLI precedence works by tail position).

karva_cache

crates/karva_cache/src/cache.rs gains coverage for write_last_failed / read_last_failed (round trip, overwrite, missing file returns empty, cache dir is created on write) and for prune_cache. The most useful test is prune_cache_keeps_newest_even_when_names_are_lexicographically_out_of_order: run-9 sorts lexicographically after run-100, so a naive string sort would delete the newest run. This test locks in the numeric sort_key behavior. There are also tests that prune_cache ignores non-run-* entries, that it handles a missing cache directory, and that clean_cache reports whether it actually removed anything. aggregate_results_merges_failed_tests_and_durations_across_workers exercises the failed-test and duration merge paths that the existing stats-merge test did not touch.

karva_project

crates/karva_project/src/path/utils.rs already tested the basic absolute cases. The new tests cover the edge cases integration tests cannot reliably reach: an empty relative input falls back to cwd, ../.. past the filesystem root stays at / instead of producing .. in the result, Unicode path components (カルヴァ/ユーザー) and paths with spaces round-trip unchanged, a trailing slash is normalized away, and . resolves to the cwd.

karva_logging

crates/karva_logging/src/time.rs had no tests at all. format_duration is one of the most visible output formats in the tool, and it has a subtle < 2s cutoff — the new tests cover 0, sub-millisecond (truncates to 0ms), the exact one-second boundary (1000ms, still in ms), 1999ms, the 2.00s switch to seconds, and a larger value like 125.00s. A rounding test pins down the two-decimal formatter (the behavior is banker's rounding via {:.2}, which surprised me — see follow-ups). format_duration_bracketed gets width/padding tests at zero, 15ms, and a large value that overflows the usual 8.3 width.

Follow-ups

While writing the tests I noticed that format_duration's two-decimal formatting uses the standard {:.2} formatter, which uses banker's rounding (2.345 formats as 2.34, not 2.35). This is fine but worth knowing if anyone ever tries to snapshot-test a duration near a rounding boundary. No code change required.

Test Plan

• cargo test -p karva_metadata -p karva_cache -p karva_project -p karva_logging --lib
• just test (866 passed)
• uvx prek run -a

[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/unit-data-crates (d875eae) with main (c05b0d3)}

[MatthewMckee4]

Superseded by #670