Add WP Rocket settings no-broken-links check

[hanna-meda]

Description

Fixes #301
Adds a new test to ensure links on WP Rocket settings screens are not broken.

Type of change

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).
• Sub-task of #(issue number)
• Chore
• Release

Detailed scenario

What was tested

• Ran command npm run test:brokenlinks that installs/activates WP Rocket and checks settings UI links return non‑404.

• Sanity check: ran the same scenario with link logging enabled to verify the collected URLs were correct.

How to test

Run npm run test:brokenlinks

Affected Features & Quality Assurance Scope

WP Rocket admin settings UI only (link integrity).

Technical description

Documentation

The step collects all a[href] within WP Rocket settings content across tabs, filters out non-navigational links and admin-post actions, normalizes URLs, and asserts none return 404.

New dependencies

None.

Risks

Potential flakiness from external sites (transient 5xx/timeout). Mitigated by only failing on 404 and allowing redirects.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Unticked items justification

N/A

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[Copilot]

Pull request overview

This PR adds a new end-to-end test to validate that links in the WP Rocket settings UI are not broken (returning 404 status). The test navigates through all WP Rocket settings tabs, collects all links, filters out non-navigational URLs, and verifies each link returns a non-404 status code.

Changes:

• Adds new Cucumber feature file for broken links testing with @brokenlinks, @smoke, and @setup tags
• Implements step definition that collects links from WP Rocket settings tabs, normalizes URLs, and validates HTTP responses
• Adds npm script test:brokenlinks for convenient test execution

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
src/features/broken-links.feature	Defines the Cucumber scenario for broken links test with appropriate tags
src/support/steps/broken-links.ts	Implements the step definition with link collection, URL normalization, and HTTP validation logic
package.json	Adds test:brokenlinks npm script following existing project patterns

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 7 comments.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

[Mai-Saad]

LGTM

• As per @jeawhanlee feedback

I noticed we seem to be throwing errors lately, which I understand is for easy debugging, But we need to perform assertions where necessary like hereGenerally, I think we can throw errors in logic that leads to expectations, but for the expectation itself, we should assert.

Agree.

Notes for test(better have screenshot of results):

• Recommend to try to edit link in WPR before having zip to be 404 and ensure that the test fails
• Run all e2e should be green

[hanna-meda]

@Mai-Saad, @jeawhanlee, thank you both. Below are two screenshots: one showing a test failure due to a 404 link, and another showing the full E2E run. In the E2E run, 61 tests passed and 1 failed; the failed test is unrelated and is due to missing Cloudflare credentials.