Summary
startup::boot::tests::print_startup_info_matches_snapshot (in src/startup/boot.rs) passes under cargo-nextest but fails under plain cargo test, because it depends on nextest's process-per-test isolation.
Detail
The test captures stdout at file-descriptor level with gag::BufferRedirect::stdout() and snapshots what print_startup_info writes:
- Under nextest, each test runs in its own process with no in-process output capture, so
println! output reaches the real stdout file descriptor and the redirect captures it.
- Under plain
cargo test, libtest's in-process capture diverts println! from the test thread into its own buffer, so nothing reaches the file descriptor. The redirect captures an empty string and the insta snapshot assertion fails:
---- startup::boot::tests::print_startup_info_matches_snapshot stdout ----
...
snapshot assertion for 'startup_info_stdout' failed in line 195
test result: FAILED. 49 passed; 1 failed; ...
Reproduce with:
cargo test --features test-helpers --bin ironclaw print_startup_info_matches_snapshot
(cargo nextest run --features test-helpers -E 'test(print_startup_info_matches_snapshot)' passes.)
Why it matters
- Any contributor running plain
cargo test (or make test-cargo) sees a spurious failure.
- Tooling that drives plain
cargo test — notably cargo-mutants' default test tool — cannot establish a passing baseline. The scheduled mutation-testing workflow works around this by passing --test-tool=nextest, mirroring the previous bespoke workflow; removing the isolation dependency would allow dropping that workaround.
- Because
cargo test aborts at this binary, the suite's doctests are also never reached under plain cargo test, leaving them unvalidated by that route.
Possible fixes
- Run the test in a subprocess (e.g. spawn itself with an env-var guard) so fd capture is deterministic under both runners; or
- have
print_startup_info write to an injected impl Write and snapshot that directly, dropping the gag redirect; or
- mark the test
#[ignore] under plain libtest with an explanatory comment.
Summary
startup::boot::tests::print_startup_info_matches_snapshot(insrc/startup/boot.rs) passes under cargo-nextest but fails under plaincargo test, because it depends on nextest's process-per-test isolation.Detail
The test captures stdout at file-descriptor level with
gag::BufferRedirect::stdout()and snapshots whatprint_startup_infowrites:println!output reaches the real stdout file descriptor and the redirect captures it.cargo test, libtest's in-process capture divertsprintln!from the test thread into its own buffer, so nothing reaches the file descriptor. The redirect captures an empty string and the insta snapshot assertion fails:Reproduce with:
(
cargo nextest run --features test-helpers -E 'test(print_startup_info_matches_snapshot)'passes.)Why it matters
cargo test(ormake test-cargo) sees a spurious failure.cargo test— notably cargo-mutants' default test tool — cannot establish a passing baseline. The scheduled mutation-testing workflow works around this by passing--test-tool=nextest, mirroring the previous bespoke workflow; removing the isolation dependency would allow dropping that workaround.cargo testaborts at this binary, the suite's doctests are also never reached under plaincargo test, leaving them unvalidated by that route.Possible fixes
print_startup_infowrite to an injectedimpl Writeand snapshot that directly, dropping thegagredirect; or#[ignore]under plain libtest with an explanatory comment.