Repository navigation
Identify gaps in unit and e2e test coverage #1863
Description
Review existing unit and e2e tests for the GatherPress migration work, identify coverage gaps, and improve coverage.
{{ message }}
Review existing unit and e2e tests for the GatherPress migration work, identify coverage gaps, and improve coverage.
Activity
wppoland commentedon Aug 8, 2026
Not picking this up, it is Dan's and I do not want to duplicate it. Some material from reviewing the in-flight Groups PRs today, in case any of it saves audit time.
Measured against
productionrather than eyeballed:Frontend JS looks like the largest single gap.
wporg-groups-frontendhas 9 block directories and 14view.js/index.jsfiles, against exactly one file intests-js/(event-rsvp.test.js).Authorization is in better shape than a quick look suggests, so it may not deserve a high slot.
tests/test-capabilities.phpalready carries negative cases (test_current_user_can_manage_events_false_when_logged_out,test_editor_does_not_have_promote_users), andgroups/tests/test-network-messaging.phpasserts that group administrators cannot send messages. The convention exists and is tested; the gap is newer code not following it. The archiving helper in #1854 is the current example, where the onlymanage_sitescheck is inline in the admin handler and no test asserts a refusal.Accessibility has exactly one e2e spec.
tests/e2e/event-rsvp-accessibility.spec.jsexists only because of a single bug report (#1812, fixed in #1852). The new blocks introduced in #1860 have no equivalent, and there is no general a11y sweep.One concrete candidate for the priority list. The draft-to-publish path for recurrence in #1846 has no coverage on either side, and I found a real defect there today: the organiser's recurrence rule is silently discarded at publish time and the request still reports success. That is the kind of thing a single integration test would have caught, so it may be a useful shape to generalise from.
Happy to answer questions on any of the above, but the audit itself is yours.
dan-zakirov commentedon Aug 9, 2026
Thanks, this was helpful. I completed the audit against current production and opened #1866 for the highest-value production gap that did not overlap with in-flight work.
The largest remaining gaps are:
I did not duplicate the existing capability tests or the recurrence draft-to-publish work, since #1865 now covers that regression.
#1866 adds focused Jest coverage for a successful notification preference update, rollback on failure, and ignoring duplicate changes while a slow save is pending. All GitHub Actions checks for #1866 are green. Local validation also passed with 10 JavaScript tests, 106 WordCamp Groups PHPUnit tests (236 assertions), the existing RSVP accessibility spec, and two browser runs against the local WordPress/GatherPress stack. The checkbox updated immediately, while the local REST request took 6 to 10 seconds, and the in-flight guard kept it to exactly one request.
bor0 commentedon Aug 10, 2026
Let's also identify crucial e2e flows like creating event, notifications, etc. and also check those
Groups: add post-upgrade code-audit and test-extension steps to the c…
Groups: add regression coverage for the #1874 class of bug
Groups: add #1874 regression coverage, and fix real bugs its E2E run …
dan-zakirov commentedon Sep 1, 2026
Checked again against current production. The crucial browser flows now covered are organizer event creation and publishing, a single member notification on first publish with no duplicate after later edits, event-management messaging and role restrictions, weekly recurrence setup, the member directory, and exports.
The highest-value e2e gaps left are a real logged-in and anonymous RSVP attend/cancel lifecycle, group provisioning, venue create/reuse/update with static-map rendering, a GatherPress-deactivated runtime smoke, and broader keyboard/axe coverage for the newer blocks. I would prioritize the RSVP lifecycle next.
Tests: cover REST authorization, the RSVP lifecycle, and venue reuse (#…