feat(Playwright): add a11y regression testing - BED-7788#2859
Conversation
| <div className={classes.applicationContainer} id='app-root'> | ||
| {showNavBar && <MainNav mainNavData={mainNavData} />} | ||
| <div className='bg-neutral-1 grow overflow-y-auto overflow-x-hidden'> | ||
| <div id='content-wrapper' className='bg-neutral-1 grow overflow-y-auto overflow-x-hidden'> |
There was a problem hiding this comment.
This adds an easy and repeatable selector to only capture the page component content, omitting the Nav menu, which may be tested in isolation. This reduces overhead for Axe Core. This is purely for makeAxeBuilder analyze targeting. User-perspective selectors (byRole, byLabel, etc) are still used to gauge loading and viewable content state.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds Playwright+ Axe accessibility testing: a shared bh-playwright-testing package (fixtures, Axe helpers, stubs), Playwright a11y config and scripts, global setup to snapshot auth state per theme, multiple a11y specs, docs, minor UI tweaks, and workspace/build integration. ChangesAccessibility testing framework
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Suggested labels
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
||
| import { expect, expectNoAccessibilityViolations, test } from 'bh-playwright-testing'; | ||
|
|
||
| test.describe('Login page accessibility', () => { |
There was a problem hiding this comment.
An example of an exceptional test. All other tests are pre-authed. But to test login we need to first wipe out the auth.
| const GRAPH_HAS_DATA_QUERY = 'MATCH (A) WHERE NOT A:MigrationData RETURN A LIMIT 1'; | ||
|
|
||
| test.describe('No Data Available dialog accessibility', () => { | ||
| test('upload dialog has no detectable WCAG A/AA violations', async ({ page, makeAxeBuilder }, testInfo) => { |
There was a problem hiding this comment.
Another exceptional test. Cypher graph state is stubbed to ensure "No Data" dialog is not present. To test this dialog, we change the stub to be explicitly empty.
| @@ -1 +1,6 @@ | |||
| TARGET_PROXY_URL="http://localhost:8080" | |||
|
|
|||
| A11Y_TEST_URL="http://127.0.0.1:3000" | |||
There was a problem hiding this comment.
I need to double check that the README explicitly mentions that adding these .env vars is required for authing test sessions.
| "noFallthroughCasesInSwitch": true, | ||
| "declaration": true, | ||
| "declarationMap": true, | ||
| "baseUrl": ".", |
There was a problem hiding this comment.
The only real change here is removing the baseUrl, which is a deprecated practice. The rest is just whitespace.
253075d to
d60928d
Compare
| "justfile", | ||
| filepath.Join("cmd", "api", "src", "api", "static", "assets"), | ||
| filepath.Join("cmd", "api", "src", "cmd", "testidp", "samlidp"), | ||
| filepath.Join("cmd", "ui", "playwright"), |
There was a problem hiding this comment.
This ensures that just prepare-for-codereview ignores any of the generated a11y test artifacts.
963cc93 to
0987d6b
Compare
763e84f to
3bbf6ea
Compare
3bbf6ea to
5f2e620
Compare
| // shared UI shell (login form labels "Email Address" / "Password", the LOGIN submit button, | ||
| // the `global_nav-dark-mode` toggle, and the `persistedState` localStorage key written by | ||
| // the global store's throttled subscriber) being identical across consumers. | ||
| export async function loginAndSnapshotThemes(opts: LoginAndSnapshotThemesOptions): Promise<void> { |
There was a problem hiding this comment.
We can reduce some of the complexity here by only persisting the auth token since the difference between the two persisted files is a toggle on the darkMode boolean.
A helper that produces a certain local storage state similar to what is done in the login spec would allow for more flexibility.
| } | ||
| return route.fulfill({ | ||
| json: { | ||
| data: { |
There was a problem hiding this comment.
There are some mock factory utilities in the ui projects that produce similar shapes of data. It would be nice to share and reuse some of these for related ideas to be coupled and maintained together. I could see us making a different package in packages/javascript specifically for this so that both unit tests and integration tests can consume them.
That would be too much for adding here but I wanted to voice that so it's on our minds.
There was a problem hiding this comment.
This is a good consideration. My main concern is dependency shape. bh-playwright-testing is a small, mostly agnostic helper package. Pulling in a dep from bh-shared-ui (where our mocks are) would introduce React, js-client-library, msw, doodle-ui...the whole stack. This could especially get tricky when we try to point Playwright at Doodle directly to do component testing.
One solution we could consider would be to generate the mocks at the app level (at cmd/ui) and pass those values in with installGraphHasDataStub. I'll try that out and see how it goes. The other alternative that comes to mind would changing this playwright lib to be a generalized testing lib, and move all the mocks and fixtures in here.
What do you think?
There was a problem hiding this comment.
True, dep shape could get tricky. I was describing having a sibling package in packages/javascript, maybe packages/javascript/mocks, though we probably need to isolate types better in advance. Having response types generated from the open api spec would help get us there.
Passing in the mock sounds like a good solution for this case but no need to make any changes unless you want. My comment was a general observation and thought about similar patterns and maintenance but I don't have a solid idea of what that should look like 😄
urangel
left a comment
There was a problem hiding this comment.
Great work! Looking forward to having this run in CI
5f2e620 to
fc08cc4
Compare
Description
Add accessibility regression testing suite via Playwright
Motivation and Context
Resolves BED-7788
How Has This Been Tested?
Tested by manually running new testing suite locally
Screenshots (optional):
Types of changes
Checklist:
Summary by CodeRabbit
New Features
Tests
Documentation
Chores
Bug Fixes