test: round 4 — an assertion that could not fail, and a comment that did not add up

Two findings, both in the review's own work; nothing in the product code. That is the shift that ends the loop: 22 → 13 → 6 → 2, and the last two are a test and a comment rather than a defect. The "an override that is fine is still honoured" leg of the bounds-fallback test stored `spec.max` — which, for this key, IS the env default, because the spec's max is derived from it. So the assertion was satisfied by the fallback it existed to rule out: mutating `_coerce` to reject EVERY int override left all three legs green. It stores `spec.max - 1` now and asserts the value differs from the default, so the leg can actually fail. And the shrink test's comment claimed `3 - 5 = -2` for an expression that computes `chips.length - visible` = `2 - 3 = -1` — naming neither operand nor the result, in a comment that was rewritten one round earlier precisely for miscounting.
2026-09-22 00:22:30 +02:00
parent 3f24248e01
commit 8525666913
2 changed files with 8 additions and 3 deletions
@@ -75,7 +75,7 @@ describe("TagFilterChips — the overflow menu", () => {
    //
    // So `fit.visible` is left ALONE across the shrink — that staleness is the precondition, not a
    // convenience of the mock. Five chips of which three fit, then three of them are deleted in the
-    // tag manager: 3 - 5 = -2.
+    // tag manager — so the shrink render computes `chips.length - visible` = 2 - 3 = -1.
    const five = ["alpha", "beta", "gamma", "delta", "epsilon"].map(chip);
    fit.visible = 3;
    const { rerender } = render(<TagFilterChips chips={five} />);