CROSS-REPO

Cross-repo test impact: when your E2E suite lives in another repo

Updated June 2026 · 6 min read

Many teams keep their end-to-end automation in a dedicated repo — separate from the app it tests. It's good hygiene: different owners, different release cadence, no test churn in app history. It also quietly removes the one signal that would tell a developer their change broke a test.

The boundary problem

When tests and app share a repo, at least the failing spec shows up in the same CI run and the same blame history. Split them, and the connection vanishes:

• The frontend dev opens a PR in the app repo. CI there is green — there are no E2E tests to run.
• The PR merges. A scheduled or downstream run in the automation repo goes red hours later.
• The QA engineer who owns that repo inherits a failure with no link back to the PR that caused it.

The dev never sees it. The reviewer never sees it. The cost lands on whoever owns the other repo, after the fact.

Why normal tooling can't help here

Coverage tools, "affected test" selectors, and CI test-splitting all operate within a single repo and a single test run. They have no concept of "a change here breaks a test there." GitHub's own PR view shows the diff and that repo's checks — nothing about a sibling repo. The boundary that makes the split clean is the same boundary the tooling can't cross.

Restoring the signal

The fix is to make the relationship explicit and analyze across it. Testward does this with a one-line config in the app repo:

# .testward.yml  (in your app repo)
automation_repos:
  - your-org/e2e-tests
  - your-org/mobile-automation

On every PR in the app repo, Testward:

1. Extracts the anchors the diff touches — selectors, routes, ids, labels, visible text.
2. Searches the linked repos' spec files for those anchors (whole-repo code search, with a tree-and-grep fallback for large suites).
3. Confirms with an LLM which specs genuinely break and why.
4. Comments on the app PR: "🚨 Automation this PR may break" — listing specs in the other repo, by path.

Now the developer learns, at review time, that their selector rename will break e2e-tests/checkout.spec.ts — and can coordinate the fix before merging instead of after the red.

This is the part no other tool does

Plenty of tools review a diff. The cross-repo link — a frontend change in one repo flagging the exact E2E spec it breaks in another — is the wedge. If your automation is split out (and on serious teams it usually is), this is the gap. See the full cross-repo setup →