Four commits landed on this branch from review while the layout wiring was in progress, and the two solved overlapping problems differently. Theirs made elementKeys() append every layout-only key, matched by exact name. Against football that also lists `score` and `odds` -- entries the alias resolution already pairs with score_text and odds_text -- so those offsets would get two controls posting the same field. The row split here (styleRows via core's x-layout-key, positionRows for what nothing claims) replaces that append; elementKeys() is back to listing style elements only. Theirs also covered cases this side had missed, all kept: - A leaf straight under layout (a show_logo toggle, no x/y object) now gets a position row with a self-keyed column bound to customization.layout.<key>. Core no longer lets an element claim a leaf as its offsets. - Leaf columns keep their namespaced id, so a leaf sharing a name with another entry's axis cannot be shadowed. - columnsFor(schema) still works with one argument (every row), so their column tests run unchanged. - The owned key is CSS.escape()'d before it becomes a selector. test_style_editor_element_keys.js is rewritten for the new contract, and says why the old one had to go. All six JS suites pass; in a browser football's 92 layout fields each render once, and a synthetic leaf -- including one named `scale` alongside a `scale` axis -- gets exactly one correctly named control. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.6 KiB
Web-interface JS tests
Covers web_interface/static/v3/js/plugins/list_filter.js (the shared
search/filter/sort controller) and the plugin-manager grids that use it:
Installed Plugins, the Plugin Store, and Starlark Apps.
There is no JS toolchain in this repo, so these are plain node scripts with no
test framework. Each prints ok/FAIL lines and exits non-zero on failure.
Running
cd test/js
npm install # jsdom, for the DOM suites only
node run_all.js
The unit suites need nothing but node. The DOM suites additionally need a running web interface, because they test against the real server-rendered HTML and the real API rather than fixtures:
# in another shell, from the repo root
EMULATOR=true python3 web_interface/app.py # http://localhost:5000
# or point the suites at a device
BASE=http://10.0.10.169:5000 node run_all.js
run_all.js skips the DOM suites (rather than failing) when jsdom is missing or
nothing is listening, so it stays useful in a bare checkout.
The suites
| Suite | Needs a server | Covers |
|---|---|---|
unit/test_list_filter.js |
no | ListFilter search/filter/sort/count/sticky, and the installed-plugins config extracted verbatim from plugins_manager.js so the test can't drift from it |
unit/test_render_cards.js |
no | renderInstalledCards markup, both empty states, and HTML-escaping of hostile plugin metadata |
unit/test_style_editor_element_keys.js |
no | elementKeys()/styleRows()/positionRows() from widgets/style-editor.js: every customization.layout entry gets exactly one row -- paired with its style element through core's x-layout-key (so score belongs to score_text, not a second row), or a position row of its own, leaves included -- since the widget claims the whole layout block from the generic fallback renderer |
unit/test_style_editor_layout_leaf_columns.js |
no | columnsFor() from widgets/style-editor.js: a layout-only key whose own value is a leaf (no x/y sub-object, e.g. a show_logo toggle) gets a self-keyed column instead of a blank, uneditable row |
unit/test_style_editor_layout_leaf_collision.js |
no | columnsFor() from widgets/style-editor.js: a layout-only leaf key still gets its own column even when its name collides with an unrelated element's style sub-field or another layout axis's sub-field |
dom/test_installed_dom.js |
yes | The toolbar in a real DOM: pill/search/sort interaction, the HTMX partial re-swap, and a getComputedStyle check that .filter-pill[data-active] really matches the emitted markup |
dom/test_store_dom.js |
yes | Store pagination, per-page, category, tri-state Installed button, and persistence across a re-boot, against the live registry |
dom/test_no_double_fetch.js |
yes | Loads the whole plugins_manager.js and counts requests: typing in the store search must filter the cached list, not refetch /api/v3/plugins/store/list |
dom/test_tools_sections.js |
yes | The Tools tab's MQTT bridge and Pixlet editor sections: form prefill, the write-only password (blank means unchanged), the running-session banner and countdown, and that the editor link points at the host you loaded the page from |
Point the DOM suites at a rig with a full plugin set when it matters — a dev box with two plugins installed will pass while exercising very little.
Notes for whoever changes this next
- The suites read the shipped files off disk and, for the DOM ones, the partial from the running server. They do not keep their own copy of the markup, so renaming an element id will fail them loudly rather than silently pass.
unit/test_list_filter.jsevals a slice ofplugins_manager.jslocated by the textfunction installedSortName(plugin). If that function is renamed, fix the slice markers rather than pasting a copy of the config into the test.- A few assertions exist specifically to stop earlier bugs coming back:
trailing spaces surviving the search debounce; a multi-word query that spans
two adjacent search fields (field order in the haystack is load-bearing);
window.installedPluginsstaying at full length while the grid is filtered. - Watch for assertions that can pass vacuously. Several here deliberately guard against it — e.g. counting only non-skeleton cards, and asserting a search phrase matches something before comparing two results.
The old-vs-new differential suites used to verify that the store and Starlark migrations were behaviour-preserving are not included: they compared against the pre-refactor implementation, which now only exists in git history. See PR #540 if that comparison ever needs redoing.