test: tests that assumed an idle machine wait for what they assert, or carry a budget for their work

Under a busy machine (the gate's lanes side by side, 12 busy cores) these went red at random: a press landed while the button was still busy, an answer was settled before it was asked for, a page grew past one wait's budget, a lazy chunk was transformed inside a 1 s wait, focus was taken a frame after the press. They now wait for the condition they depend on, preload the chunks they open, and the tests that do heavy work (whole-repo scans, the type-aware linter, module resets) carry an explicit budget naming that work. The whole suite four times under 12 busy-loop processes: red 4/4 before, 0/4 after.
2026-10-17 01:08:15 +02:00
parent 926e5e9899
commit 5ba5679239
18 changed files with 181 additions and 96 deletions
@@ -394,6 +394,11 @@ describe("a Plex title's menu — Add to collection", () => {
    // Retry from the keyboard: the focused button goes as the list loads, and focus must not be left
    // on <body> with the menu open — it lands on the first row that came back.
    const retry = (await screen.findByText("common.retry")).closest("button")!;
+    // The menu takes the focus a frame after it opens. Wait for that: a frame that came only after the
+    // press would put the focus back on the panel over the hand-over below — a test faster than a
+    // frame, not a reader, who cannot press a Retry they have not seen painted yet.
+    const panel = retry.closest("[data-floating-ui-portal]")!;
+    await vi.waitFor(() => expect(panel.contains(document.activeElement)).toBe(true));
    retry.focus();
    fireEvent.click(retry);
    const beta = await checkRow("Beta");