End-to-end tests for automatic approval, against a stubbed AWS SSO

[popen2]

This is the testing PR. It changes no behaviour — it tests what main does today. The behaviour change that came out of writing it is #90, stacked on this.

Rebased onto main at 7522d2e (after #92).

Why

Automatic approval is a script clicking buttons on pages Frost does not own, in a window the user cannot see. Every way it can be wrong is quiet — a button never found (the refresh hangs until the device code expires), a button that should not have been clicked (the request is denied), a hand-over that never happens (the user waits in front of nothing). Testing the matching rules alone misses what actually makes it work: the whole path.

So npm run test:auto-approve drives the real refresh() — the entry point the tray, the hotkey and the timer use — and asserts on what the user would have seen.

Ten… nine scenarios

Scenario	What must be true
Portal session live	Token collected, no window ever shown, no notification
AWS redirects to the IdP, session live there	Same — the hop happens and still nothing is shown
AWS redirects to the IdP, it wants a password	Window shown; after the test signs in, the driver finishes the approval
Notify mode	Nothing opens until triggerPendingAuth(), even when the approval needs nobody
Default-browser mode	openExternal gets the verification URL, no window shown
Automatic approval off	Window visible from the start, nothing driven
IdP page with an "Allow access" button	Never clicked — the label the driver wants, on a host that is not ours
AWS page with nothing recognisable	Nothing clicked, including a refusal wearing cli_login_button's id
Nobody at the machine (#92's parking)	The login is held hidden, then shown when presence returns

What makes it possible

Four interceptions, none of which asks the app to know it is under test:

• AWS_ENDPOINT_URL_SSO_OIDC / AWS_ENDPOINT_URL_SSO — an AWS SDK feature, so the device authorization, the polling and its AuthorizationPendingException are the real client speaking a real protocol. The token only becomes redeemable when the stub's approval page is actually fetched, so nothing passes without a real click.
• session.protocol.handle("https", …) — pages served at their real names, so the renderer gets https://d-1234567890.awsapps.com, a secure context, and a genuine cross-origin 302 to https://idp.example.test. Served from localhost this would prove nothing; the host rule is the point.
• Notification.prototype.show and shell.openExternal recorded, not performed — a CI runner has neither a notification daemon nor a browser. Notification is a non-configurable export, hence the prototype.
• powerMonitor.getSystemIdleTime() answers what the scenario says — Keep trying an overnight sign-in instead of giving up on it #92 made Frost show a login page only to somebody who is there, so real idle time would make these depend on whether anyone touched the keyboard: green on a fresh CI runner, red on a desktop five minutes after you start them and walk away.

HOME and the electron-store move to a temp directory, so a run touches nothing of the developer's.

It fails when the feature breaks

Each mutation fails exactly one scenario:

Mutation	Fails
isApprovalHost → false	silent approval, federated session
isApprovalHost → true	identity provider (clicks its "Allow access")
isDenial → false	unrecognised page (clicks the id trap)
isUserPresent → true	nobody at the machine (shows a window to an empty room)

Also here: the tests report as tests

The first commit renames check:overlay → test:overlay (and its file), and moves it out of the job called 🧹 Lint app into 🧪 End-to-end tests, which build waits on. Both real-app tests now report under a name that answers "did the tests run" from the check list.

Still not covered

A real desktop — no security key, no keychain, no dock — and the real AWS pages, so the id and label matching against what AWS serves today still wants a smoke test on a real machine.

🤖 Generated with Claude Code

https://claude.ai/code/session_018XK1mi3rSPLzxu7XUhyC6a