Assert the menu as text, not only as a photograph #10

Merged
geusebio merged 1 commit from feature/assert-the-menu into main 2026-08-15 14:11:29 +00:00
Owner

First half of #627.

The captures prove what a person would see — and have to be looked at by one. cmd/menudump prints the same tree the running binary exported over DBus, and check.sh diffs it against menu.golden:

Alice A · sc-tray @ studio — http://someones.localhost:8099  [disabled]
🔔 2 unread · billing/main failed to deploy
Open dashboard
───
acme · $412.00 ⣀⣀⣠⣴⣷⣦⣄⣀⣀⣀⣀⣀ · ≈ 76d left  [disabled]
   shop · #12
  ● main · running (#12)
    Activate main  [hidden]
    Confirm stop main
  ○ staging · built (#4)
    Activate staging
    Confirm stop staging  [hidden]
  Open in browser

Labels, order, nesting, and which rows are disabled or hidden — so a row moving fails the build instead of waiting to be noticed in a PNG diff. That is the difference between a screenshot suite and a test suite. Verified both ways: the check exits 1 on a changed menu and 0 when it matches.

Two things this had to get right

  • The bus name carries the tray's pid, so the menu is found by prefix rather than assumed — and sorted, so a stale item from a crashed run gives a stable answer rather than a coin toss.
  • A child arrives as a variant wrapping (ia{sv}av), which godbus hands back as []interface{} rather than as the typed struct it decodes the outermost reply into. Getting that wrong is silent: it produced an empty golden file that would have asserted nothing for ever. An empty dump is a hard error now, because the menu has fixed rows before it has any data.

The status row's timestamp is normalised rather than dropped — its presence and position are exactly what a golden file should hold, and only the clock in it is noise.

Still to come on #627

A scene per state (signed out, unreachable, empty, refused activation, mid-flight, gone), and the manual generated from the same run. This is the machinery both need: one scene, asserted.

First half of [#627](https://git.grey.ooo/Grey.ooo/Someones.Computer/issues/627). The captures prove what a person would see — and have to be looked at by one. `cmd/menudump` prints the same tree the running binary exported over DBus, and `check.sh` diffs it against `menu.golden`: ``` Alice A · sc-tray @ studio — http://someones.localhost:8099 [disabled] 🔔 2 unread · billing/main failed to deploy Open dashboard ─── acme · $412.00 ⣀⣀⣠⣴⣷⣦⣄⣀⣀⣀⣀⣀ · ≈ 76d left [disabled] shop · #12 ● main · running (#12) Activate main [hidden] Confirm stop main ○ staging · built (#4) Activate staging Confirm stop staging [hidden] Open in browser ``` Labels, order, nesting, and which rows are disabled or hidden — so **a row moving fails the build** instead of waiting to be noticed in a PNG diff. That is the difference between a screenshot suite and a test suite. Verified both ways: the check exits 1 on a changed menu and 0 when it matches. ## Two things this had to get right - **The bus name carries the tray's pid**, so the menu is found by prefix rather than assumed — and sorted, so a stale item from a crashed run gives a stable answer rather than a coin toss. - **A child arrives as a variant wrapping `(ia{sv}av)`**, which godbus hands back as `[]interface{}` rather than as the typed struct it decodes the outermost reply into. Getting that wrong is *silent*: it produced an empty golden file that would have asserted nothing for ever. An empty dump is a hard error now, because the menu has fixed rows before it has any data. The status row's timestamp is normalised rather than dropped — its presence and position are exactly what a golden file should hold, and only the clock in it is noise. ## Still to come on #627 A scene per state (signed out, unreachable, empty, refused activation, mid-flight, gone), and the manual generated from the same run. This is the machinery both need: one scene, asserted.
Assert the menu as text, not only as a photograph
All checks were successful
CI / build (pull_request) Successful in 28s
2c3dcfcdb7
The captures prove what a person would see and have to be looked at by one.
cmd/menudump prints the same tree the running binary exported over DBus —
labels, order, nesting, and which rows are disabled or hidden — and check.sh
diffs it against menu.golden, so a row moving fails the build instead of
waiting to be noticed in a PNG.

That is the difference between a screenshot suite and a test suite, and it is
the first half of the platform repo's #627.

Two things this had to get right. The tray registers its menu at a fixed path
under a bus name carrying its pid, so the name is found by prefix rather than
assumed. And a child arrives as a variant wrapping (ia{sv}av), which godbus
hands back as []interface{} rather than as the typed struct it decodes the
outermost reply into — getting that wrong is silent, and produced an empty
golden file that would have asserted nothing for ever. An empty dump is now a
hard error, because the menu has fixed rows before it has any data.

The status row's timestamp is normalised rather than dropped: its presence and
position are exactly what a golden file should hold, and only the clock in it
is noise.
Sign in to join this conversation.
No reviewers
No labels
in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Grey.ooo/someones.computer_tray!10
No description provided.