test: the Settings view has no browser coverage, so a wrong element id takes the whole screen down undetected #229
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Nothing exercises the Settings view in a browser. The e2e suite never navigates there, and jest runs in the node environment with no DOM, so every
$("settings-...")lookup insrc/popup/views/settings.jsis unverified at runtime.Consequence: a single wrong element id makes
init()throw and takes the entire Settings screen down — network selector, theme, spam filters, wallet management, the lot.make checkpasses, review passes on a static grep, and the user finds it.This is precisely the undefined-identifier class that shipped as #150 and #151. Settings is the densest concentration of id lookups in the codebase and has the least coverage of any screen.
Raised while adding a new checkbox in #176, where the author correctly flagged that their static verification was weaker than a run.
Partly overlapping but NOT a substitute: #152 adds ESLint, which would catch a genuinely undefined identifier. It would not catch a string id that is valid JavaScript but does not match any element in
index.html— which is the actual failure mode here.Implementation requirements
console.erroras a failure, so confirm a throwninit()actually surfaces that way rather than being swallowed.$("...")id referenced by the view modules exists insrc/popup/index.html. That catches the whole class rather than the ids one test happens to touch, and is a static check that could run inmake check.Definition of done
settings.jsfails the suite — demonstrated, with captured output.TODO.mdupdated in the same commit.make checkpasses.Plan.
e2e (Chrome suite,
tests/e2e/run.js) — a new Settings section, additive, following the existing shape and reusing theopenSettings()helper already there:#view-settingsrenders;input[type=checkbox], and default to checked (hideSpoofedSymbols,hideLowHolderTokens,hideFraudContracts,hideDustTransactionsall defaulttrueinsrc/shared/state.js);changehandler,saveState(),loadState()and theinit()assignment, not just visibility;#settings-networkand#settings-themeareselectelements whose options matchNETWORKS/ the three theme values and whose current value equals persisted state.Placed after the address-removal section so it runs before the sections that own the fixture state, and it leaves the popup back on
#view-main.Skip-detection. Each Settings test records a coverage key in
env; a final guard test asserts the recorded set equals the expected set exactly. An early return, a deleted test or a silently-swallowed body then fails the run rather than shrinking it quietly.Thrown
init().settings.init(ctx)runs from theDOMContentLoadedhandler insrc/popup/index.js, so a wrong id throws inside an async function, i.e. as a promise rejection rather than a synchronous throw. I will verify empirically that that reaches the harness collector as apageerror/console.errorand fails the run, rather than assuming it — and if it is swallowed, the fix goes in the harness.Demonstration. Break one id in
src/popup/views/settings.json theshow()path and one on theinit()path, capture both failing runs into the PR body, then revert.Static guard. A jest test asserting every literal
$("id")undersrc/popup/has a matchingid="..."insrc/popup/index.html, so it runs inmake check. Measured onnext: 221 distinct referenced ids, 274 ids in the markup, 0 missing — no false positives today. Scoped to$("...")deliberately: literaldocument.getElementById("...")would drag indebug-banner, which is created at runtime and legitimately absent from the markup.TODO.mdin the same commit.