Fell out of review on #10. Not a bug — a missing net.
barBrightness is asserted now, and Ship.sinceHit is asserted. The dozen lines in Hud.updateContacts that turn one into the other are asserted by nothing, because createHud needs a document and simcheck runs headless.
Three mutations to that block, each verified to pass the whole suite at 668330c — exit 0, 175 ok, 0 FAIL:
| Mutation |
Effect |
Suite |
Ignore brightness, always draw at opacity 1 |
bar never fades |
175 ok |
Drop the offscreen guard |
bar drawn on rotating edge arrows |
175 ok |
slot.barFill.style.width = (1 - hullFraction) * 100 |
bar reports the inverse of hull |
175 ok |
The third is the sharp one: a full bar would mean a nearly-dead ship, and nothing in the repo objects.
Why this was not a blocker on #10
A wrong curve is quiet. It fades slightly off, nobody notices for a month, and that is exactly why it earned assertions. A wrong wiring is loud — an inverted bar is obvious within ten seconds of play, and the block was checked in a browser before merge. What is missing is a net for whoever edits it next, not a check on whether it is right today.
What closing it costs
createHud needs a DOM. The options, roughly in order of how much they change:
- Extract the decisions, leave the writes. Pull the per-contact resolution — given
sinceHit, hullFraction and offscreen, what opacity / fill width / threshold class — into a pure function beside barBrightness, and have updateContacts do nothing but apply the result. Testable headlessly with no new dependency. Leaves the DOM writes themselves uncovered, which is the part least likely to silently invert.
- Give simcheck a DOM.
jsdom or linkedom as a dev dependency, then drive createHud directly. Covers everything including the writes, and buys real assertions on the rest of the HUD too — the corner gauges and the contact projection are equally uncovered today. Costs a dependency and some startup time in a suite that currently runs in about a second with none.
- Screenshot tests. Covers CSS, which neither of the others does — the dark backing and the size override are real design decisions with no assertion behind them. Much heavier and flakier than this repo's bar.
Option 1 is the cheapest and covers the mutations above. Option 2 is the honest fix if the HUD keeps growing.
Not urgent. Worth doing before the next person changes that block.
Fell out of review on #10. Not a bug — a missing net.
barBrightnessis asserted now, andShip.sinceHitis asserted. The dozen lines inHud.updateContactsthat turn one into the other are asserted by nothing, becausecreateHudneeds adocumentand simcheck runs headless.Three mutations to that block, each verified to pass the whole suite at
668330c—exit 0, 175 ok, 0 FAIL:brightness, always draw at opacity 1offscreenguardslot.barFill.style.width = (1 - hullFraction) * 100The third is the sharp one: a full bar would mean a nearly-dead ship, and nothing in the repo objects.
Why this was not a blocker on #10
A wrong curve is quiet. It fades slightly off, nobody notices for a month, and that is exactly why it earned assertions. A wrong wiring is loud — an inverted bar is obvious within ten seconds of play, and the block was checked in a browser before merge. What is missing is a net for whoever edits it next, not a check on whether it is right today.
What closing it costs
createHudneeds a DOM. The options, roughly in order of how much they change:sinceHit,hullFractionandoffscreen, what opacity / fill width / threshold class — into a pure function besidebarBrightness, and haveupdateContactsdo nothing but apply the result. Testable headlessly with no new dependency. Leaves the DOM writes themselves uncovered, which is the part least likely to silently invert.jsdomorlinkedomas a dev dependency, then drivecreateHuddirectly. Covers everything including the writes, and buys real assertions on the rest of the HUD too — the corner gauges and the contact projection are equally uncovered today. Costs a dependency and some startup time in a suite that currently runs in about a second with none.Option 1 is the cheapest and covers the mutations above. Option 2 is the honest fix if the HUD keeps growing.
Not urgent. Worth doing before the next person changes that block.