Which Cypress specs will this PR break?

Why Cypress suites break silently

Cypress specs select elements with cy.get('[data-cy=...]') and assert on routes and visible text. Those are exactly the things a frontend PR changes. The spec doesn't know it's broken until it runs — and the PR diff gives the reviewer no hint that a test depends on the attribute being renamed.

The cost isn't the red build; it's the context-switch. The dev who broke it has moved on, and the QA engineer inherits a failure with no breadcrumb back to the cause.

What Testward does

• Reads each PR diff and extracts the anchors it touches — data-cy, data-test, data-testid, route literals, ids, visible text.
• Scans your Cypress specs (same repo or a linked repo) for ones that reference those anchors.
• Confirms with an LLM pass and names the specific specs likely to break.
• Posts a single sticky PR comment listing the affected specs and why.

Cross-repo Cypress suites

If your Cypress tests live in a dedicated repo, link it once:

# .testward.yml
automation_repos:
  - your-org/cypress-e2e

Now app PRs flag the Cypress specs they break across the repo boundary. Cross-repo setup →

Harden the suite too

Brittle data-cy hygiene is the root cause of most Cypress flakiness. See selectors that don't break and cutting flaky-test noise.