Label the store save button, which reddened development's e2e - #1697
Merged
Conversation
MY REGRESSION, from #1677. StoreSettingsTab shipped a bare "Save" button, so `pages.spec.ts` hit a strict-mode violation: getByRole('button', { name: 'Save', exact: true }) resolved to 2 elements The convention was already written down, in that spec's own comment: the admin surface renders every section, four of them carry a LABELLED save ("Save mandate matrix settings", "Save consultation settings", …), and the bare "Save" belongs to the Configuration section alone. Mine took a name that was spoken for. Labelled rather than the test scoped, because the duplicate is a real defect in its own right: two buttons with the identical accessible name on one page give a screen-reader user no way to tell them apart. Fixing the label fixes both. WHY THIS REACHED DEVELOPMENT AT ALL, and it is the useful part: the e2e leg is SKIPPED on pull requests into development and runs only on the push. #1677 was green on 49 checks with `E2E Tests (Playwright): skipping`, so the PR could not have caught this. The 19 local Playwright tests I ran did not include pages.spec.ts. Verified against a live instance: the exact assertion that failed now passes.
rubenvdlinde
requested review from
Rem-Dam,
SudoThijn,
WilcoLouwerse,
bbrands02,
remko48 and
rjzondervan
as code owners
September 3, 2026 04:57
Contributor
Quality Report — ConductionNL/dossiq @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| build | ✅ | ||||
| check-manifest | ✅ | ||||
| check-vue3-compile | ✅ | ||||
| test-l10n | ✅ | ||||
| format | ✅ | ||||
| check-schema-l10n | ✅ | ||||
| check-l10n-js | ✅ | ||||
| composer | ✅ | ✅ 106/106 | |||
| npm | ✅ | ✅ 540/540 | |||
| app:check-code | ⏭️ | ||||
| info.xml | ✅ | ||||
| REUSE | ❌ | ||||
| PHPUnit | ✅ | ||||
| Newman | ⏭️ | ||||
| Playwright | ⏭️ deferred — runs on the promotion into beta/main, not on a pull request into development | ||||
| Hydra gates | ✅ |
Quality workflow — 2026-09-03 05:02 UTC
Download the full PDF report from the workflow artifacts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
My regression, from #1677.
StoreSettingsTabshipped a bareSavebutton, sopages.spec.tshit a strict-mode violation on the admin page:The convention was already written down
In that spec's own comment:
Mine took a name that was already spoken for. Renamed to
Save store settings, joining the four siblings.Labelled rather than the test scoped, because the duplicate is a real defect on its own terms: two buttons with the identical accessible name on one page give a screen-reader user no way to tell them apart. Fixing the label fixes both, and editing a test to accommodate new code would have hidden the accessibility problem.
Why this reached development at all
This is the part worth keeping. The e2e leg is skipped on PRs into development and runs only on the push. #1677 was green on 49 checks with
E2E Tests (Playwright): skipping, so the PR could not have caught it, and the 19 local Playwright tests I ran did not includepages.spec.ts.Any change touching the admin settings surface should run
pages.spec.tslocally before merge, because CI will not.Verified
The exact assertion that failed on development now passes against a live instance:
🤖 Generated with Claude Code