Repository navigation
test(ProgressBar): wait for the story's bar, not 5 s - #10976
Conversation
Five ProgressBar a11y tests open a story, then assert that its bar is visible within the assertion's 5 s default. Storybook renders the story only after it has loaded the story's module. In the a11y suite under CI's profile, a load spike held two of these tests past 5 s in the same second, while neighbouring tests took 36 and 42 s. The tests now wait for the bar itself, as the harness's openStory waits for Storybook's render. The test's own timeout bounds the wait, and nothing the tests judge changes.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
PR Analysis Report🔎 Preview ·
|
| Component | Size | LoC | Visual · A11y · RTL |
|---|---|---|---|
| ProgressBar · Storybook | 11.7 kB (0) · 6.3 kB CSS (0) | 568 (0) | ✓ · ✓ · ✓ |
Package size: no published package changed; no new dependencies.
API changes: none in this pull request
Committed API report behind this build: cli 29 rows, core 36 rows; run pnpm api:report.
Touched components checked; add ci:run-visual or ci:run-rtl to run the full suites.
Accessibility: 2 violation(s)
Accessibility Audit
Status: 2 accessibility violation(s) found — 2 serious.
ProgressBar - 1 issue(s)
- 🟠 serious: Ensure the contrast between foreground and background colors meets WCAG 2 AA minimum contrast ratio thresholds
- Rule:
color-contrast· Affects 2/18 stories · Learn more - WCAG: 1.4.3 (Level AA)
- Rule:
Progressbar - 1 issue(s)
- 🟠 serious: Ensure the contrast between foreground and background colors meets WCAG 2 AA minimum contrast ratio thresholds
- Rule:
color-contrast· Affects 1/1 stories · Learn more - WCAG: 1.4.3 (Level AA)
- Rule:
Generated by PR Enrichment workflow | View full report
There was a problem hiding this comment.
Approved pending CI: CI has not run on this head yet. This is a draft from a fork, so once it is marked ready, a maintainer adds the ci:run label so CI runs.
The five story opens in the ProgressBar motion and touch specs now wait for the bar within the test's own 60 s timeout, and every assertion after them is unchanged. A story that loads slowly no longer fails at 5 s, and one that never renders still fails.
- Optional:
open()inProgressBarMotion.a11y.chromium.spec.tsnow waits on.first(), which drops the strict one-bar check the old assertion had;ProgressBarTouch'sopen()keeps it.
[Automated review]
| * an assertion's 5 s for that. The test's timeout bounds the wait. | ||
| */ | ||
| async function barShown(page: Page) { | ||
| await page.getByRole('progressbar').first().waitFor(); |
There was a problem hiding this comment.
Optional: open() also waits through this helper, so its old strict getByRole('progressbar') check (exactly one bar in the Default story) becomes .first(). Touch's open() keeps the strict form. Consider letting open() call page.getByRole('progressbar').waitFor() and keeping .first() for the three indeterminate-story opens.
Maintainer impact
In the a11y suite under CI's profile (
--cpus=4,CI=1, 4 contract workers), two ProgressBar tempo tests failed in the same second on main a0e0536. Each opened its story and asserted that the bar was visible within the assertion's 5 s default. Neither bar had rendered yet. Neighbouring tests took 36 and 42 s at that moment.Intended invariant
The tests keep every claim and every bound. Only the wait for the story's first render changes: it ends on the bar itself, within the test's own timeout.
Change
d0a50f1 changes two spec files:
open()waits for its bar withwaitFor(), not a 5 s visibility assertion.open()and three tests that open the indeterminate story wait through one helper,barShown.openStorywaits for Storybook's render the same way, within the test's timeout. It has noglobals, which these tests use for RTL and colour modes.Evidence
expect(locator).toBeVisible() failed, element not found after 5 s.Scope
Testing
CI=trueESLint and Prettier on both specs, andreview:prepass.