Skip to content

Add end-to-end tests for post form security and view control features - #1932

Open
dev-shahed wants to merge 6 commits into
weDevsOfficial:developfrom
dev-shahed:e2e/post-form-e2e
Open

Add end-to-end tests for post form security and view control features#1932
dev-shahed wants to merge 6 commits into
weDevsOfficial:developfrom
dev-shahed:e2e/post-form-e2e

Conversation

@dev-shahed

Copy link
Copy Markdown
Contributor
  • Implement postFormSecurityTest.spec.ts to validate security measures for form submissions, including nonce checks, payload validation, and escaping of script inputs.
  • Create postFormViewControlTestPro.spec.ts to test view control settings, ensuring content visibility based on user roles and subscription packs.
  • Enhance subscriptionTest.spec.ts to track subscription pack counts, ensuring tests start from the correct baseline.
  • Introduce fieldTypes.ts to catalog available post-form field types for better test management.
  • Extend wpEnvCli.ts with functions to count subscription packs and manage user subscriptions for streamlined test setup.

dev-shahed and others added 6 commits August 4, 2026 17:58
- Implement `postFormSecurityTest.spec.ts` to validate security measures for form submissions, including nonce checks, payload validation, and escaping of script inputs.
- Create `postFormViewControlTestPro.spec.ts` to test view control settings, ensuring content visibility based on user roles and subscription packs.
- Enhance `subscriptionTest.spec.ts` to track subscription pack counts, ensuring tests start from the correct baseline.
- Introduce `fieldTypes.ts` to catalog available post-form field types for better test management.
- Extend `wpEnvCli.ts` with functions to count subscription packs and manage user subscriptions for streamlined test setup.
…e count

LS0010/LS0011 passed locally and failed in every CI group for two reasons,
both of which depend on how many pages the mounted plugins create:

- validateWPUFpages() paged through the Pages list with "Next page". The list
  paginates at 20 rows and WP takes that number from the per-user screen
  option only (wp_edit_posts_query() ignores a per-page URL arg), so the four
  CI groups with no extra plugins have no second page at all, while the groups
  that do spread the WPUF pages differently. Look each page up by title via
  the list-table search instead.

- validateWPUFpagesFE() used a plain locator for front-end page links, but
  Dokan also ships a "Dashboard" page, so WPUF's becomes `dashboard-2` and the
  locator hit a strict-mode violation on two matches. Use the existing
  validateAndClickAny(), which takes the first visible match and still throws
  when there is none.

Also drops the now-unused clickNextPage selector.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QjKued1RBqUQPgb1sMSaYZ
WPUF, Dokan and WooCommerce all redirect the FIRST admin page load after
activation to their own setup wizard — WPUF via the one-shot
`wpuf_activation_redirect` transient (Setup_Wizard::redirect_to_page). Which
navigation eats that redirect is a race, and it is environment-dependent: on a
long-lived local site the transients were spent long ago, but CI activates the
plugins at wp-env boot, so the first admin request of the run gets hijacked.
The CI trace for the LS0002 failure shows the chain landing on
`index.php?page=dokan-setup` and then `index.php?page=wpuf-setup`; both wizards
render full screen with no admin menu, so the test waited 30s for a Dashboard
menu item that could never appear.

Each redirect deletes its own transient, so re-requesting the URL gets us where
we asked to go. Do that in navigateToURL(), which every admin navigation in the
suite already routes through, and loop so a chain of wizards is fully consumed.
Navigations that ask for a wizard on purpose (LS0006) are left alone.

Verified locally against Docker/wp-env by arming the transient and driving
navigateToURL with an authenticated session: fails with the same
`//div[text()="Dashboard"]` timeout without the guard, passes with it. Full
setup project: 37/37 passing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QjKued1RBqUQPgb1sMSaYZ
My previous attempt swapped the front-end page-list clicks to
validateAndClickAny(), which silenced the strict-mode violation on the two
"Dashboard" links by picking the first visible one. That picked the WRONG page:
CI's trace shows the test landing on Dokan's vendor dashboard
(/dashboard/?path=%2Fanalytics%2FOverview), which renders no page-list nav at
all, so every later lookup failed with "No visible elements found".

Titles in that nav are not unique and cannot be made unique — Dokan owns
`dashboard`, so WPUF's page becomes `dashboard-2`, and which plugin wins depends
on activation order, i.e. on the environment. Resolve each WPUF page from its
admin row instead (pinned by the "— WPUF … Page" post-state badge, which only
WPUF's row carries), read its post ID, and visit `?page_id=N` directly. That is
slug-independent and ambiguity-proof, and it still asserts each page renders
(not a 404).

Verified locally against the CI plugin set, including with a decoy second
"Dashboard" page present: resolves WPUF's page, not the decoy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QjKued1RBqUQPgb1sMSaYZ
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant