Problem
Two bugs in one day came from the same fork: state set inside
call_test_functions dies with the background worker --parallel spawns.
Every test in the suite runs one mode at a time, so nothing compared the two.
Both were found by running the same fixture twice by hand and noticing the
verdicts differed.
Proposal
An acceptance test that runs the same fixture under both modes and asserts the
totals line and exit code match, over the outcome shapes a run can produce.
Worth noting what it does not cover: the original #1145, where the test
vanished outright, was not a parity bug — both modes dropped it identically.
Parity catches the half of a fix that forgets the fork, not the behaviour
itself.
--stop-on-failure is excluded: parallel stops dispatching but cannot un-run
in-flight workers, so the modes legitimately differ there.
Problem
Two bugs in one day came from the same fork: state set inside
call_test_functionsdies with the background worker--parallelspawns.--parallelwhile the sequential run rejected the same file
and not the other until it also wrote a
.resultEvery test in the suite runs one mode at a time, so nothing compared the two.
Both were found by running the same fixture twice by hand and noticing the
verdicts differed.
Proposal
An acceptance test that runs the same fixture under both modes and asserts the
totals line and exit code match, over the outcome shapes a run can produce.
Worth noting what it does not cover: the original #1145, where the test
vanished outright, was not a parity bug — both modes dropped it identically.
Parity catches the half of a fix that forgets the fork, not the behaviour
itself.
--stop-on-failureis excluded: parallel stops dispatching but cannot un-runin-flight workers, so the modes legitimately differ there.