tests: make the partially-diverged scenario actually strand a test - #75
tests: make the partially-diverged scenario actually strand a test#75cargo-affected-bot wants to merge 1 commit into
Conversation
cargo-affected-bot
left a comment
There was a problem hiding this comment.
#49 rewrites this file's module doc, and its replacement says "a single diverged sha only strands its own tests instead of widening the run". Under the distinction this PR draws, that clause describes the missing case — a diverged-but-present sha strands nothing, which is exactly why these two scenarios had collapsed into one. The hunks are disjoint, so the two merge cleanly and leave the module doc contradicting the doc comments below it; whichever lands second is the one to reword.
|
Resolved on the other side, so merge order no longer matters here. #49 pushed |
run_unions_affected_and_stranded_when_partially_divergednever stranded anything. It reset HEAD back tosha0and asserted onlycombined.contains("2 tests to run")— which passed with both tests classifiedaffected, so theaffected ∪ strandedunion it exists to pin had no coverage at all. Greppingtests/forstrandedturned up only comments; thestrandedselection category had no functional test anywhere.The cause is that reachability is object existence, not ancestry —
relation_to_headreturnsMissingonly whengit cat-file -efails. Agit reset --hardorphans the commit but leaves it in the object database, so it staysReachableand its tests come back as ordinaryaffectedhits. That's the same situationrun_uses_reachable_shas_when_one_sha_divergessets up directly above, which is why the two scenarios had quietly collapsed into one.Changes
run_unions_affected_and_stranded_when_sha_is_missing(renamed from..._when_partially_diverged) now expires the reflog and runsgit gc --prune=nowafter the reset, sosha1is genuinely gone, and asserts the actual classification rather than a bare count:2 tests to run (1 affected + 0 config + 0 new + 1 stranded— one hit from each categorytest_fa (stranded)in the per-test listingnot in the repomissing-sha notice is emitted, not silently swallowedgit cat-file -eprobe confirming the prune worked, so the scenario fails loudly rather than silently reverting to the reachable case if a future git changes gc behaviorrun_uses_sibling_sha_without_stranding_or_widening(renamed fromrun_uses_reachable_shas_when_one_sha_diverges) — nothing diverges in this scenario, and its own inline comment already said so ("So selection picks test_fa as affected, not new") while the doc comment above it claimed the opposite ("only tests stranded at the diverged sha rerun (as 'new')"). The doc comment and name now match the body, and the count assertion is tightened to1 tests to run (1 affected + 0 config + 0 new + 0 strandedso the sibling case pins the category too — if siblings ever start stranding, this test catches it rather than passing on a matching total.Both doc comments cross-reference each other, since the reachable/missing distinction is the only thing separating the two scenarios.
Verification
Per
tests/CLAUDE.md, the new assertions were seen failing against the pre-fix behavior: removing the two gc lines and re-running giveswhich is exactly the collapsed-into-
affectedshape described above. With the fix, the run reports1 affected + 0 config + 0 new + 1 strandedand tagstest_fa (stranded).Full suite green locally: 112 unit + 41 functional passed,
cargo clippy --all-targetsandcargo fmt --checkclean.This touches
tests/functional/diff_collect.rsalongside #49, but in disjoint hunks — that PR rewrites the module doc at the top of the file, this one changes two scenarios near the bottom.