Supercov's MC/DC count exposes an untested session-expiry check behind 100% branch coverage

MC/DC, short for Modified Condition/Decision Coverage, treats `signedIn && !expired` as one decision made of two conditions ^[5]. For each condition it looks for a pair of runs in which only that condition changes and the decision's result changes with it ^[5]. The valid-session test and the signed-out test form that pair for `signedIn` ^[6]. The valid-session run has no partner for `!expired`, because no run holds `signedIn` true while flipping `expired` ^[6]. Branch coverage asks only whether both return statements ran, and both did ^[1].

JavaScript complicates the count. When `signedIn` is false, `&&` never evaluates `!expired`, and the post says a tool has to keep that skipped condition distinct from a false one ^[7]. The exact witness rules depend on which form of MC/DC is being measured. The post points to Clang's coverage documentation for its masking approach ^[8]. For a two-condition decision, according to the post, the missing expired-session case is straightforward ^[8].

Adoption is a prefix on the existing test command. `npx supercov -- npm test` runs whatever follows the `--` as the project's test command, and `npx supercov runs latest gaps` lists what was not observed ^[9]. The post hedges its own numbers, and I'd count that in its favour. It calls them Supercov's counts for this file and says different tools count branches differently ^[11]. It also says ordinary branch or condition counters are not evidence that a condition independently changes a decision ^[11].

The fix was one test expecting `canCheckout(true, true)` to return false, added by a coding agent that left the application code unchanged ^[13]. The post's authors wrote the line I would underline at review: "Calling the function would exercise the condition; checking the result verifies that this input is denied checkout." ^[14] A test that called the function and asserted nothing would exercise the same condition and catch nothing ^[14]. With the assertion in place, MC/DC reaches 100% ^[1]. Deleting the expiry guard now fails the new test ^[16].

The post suggests handing gap selection to an agent with a prompt that begins "Measure code coverage with npx supercov and write one missing test. Only change tests." ^[17] I think "Only change tests" is the right constraint for a guard like this one. It holds the code fixed, so the new test has to state what the code should do. If the code were already wrong, the same constraint could lead an agent to assert the bug. The post tells readers to review the changed test and the before-and-after comparison ^[18].

The demonstration is a single two-condition function with three tests ^[2][15]. The post does not report run time or results on a larger codebase. For the 50% figure to carry over to a real auth module, its guards would need to be measured as decisions in the same way, and its tests would need to assert outcomes. In my context, I'd run the MC/DC pass first on the files holding auth and checkout guards. A missed condition there grants access or accepts an order. Elsewhere I'd keep branch coverage until the overhead is known.