Skip to content

fix(e2e): give the harness tests a timeout they can actually meet - #120

Draft
CAMOBAP wants to merge 2 commits into
masterfrom
fix/e2e-harness-test-timeout
Draft

CAMOBAP wants to merge 2 commits into
masterfrom
fix/e2e-harness-test-timeout

Conversation

@CAMOBAP

@CAMOBAP CAMOBAP commented Oct 4, 2026

Copy link
Copy Markdown
Collaborator

The e2e harness suite has been failing on master on every run since at least 2026-08-16.
It is not flaky and not environmental — it cannot pass as configured.

Each case in darkTheme.harness.js does:

await render(<WidgetFixture theme="light" />, { timeout: WEBVIEW_LOAD_MS }); // 10s
await new Promise((r) => setTimeout(r, WEBVIEW_LOAD_MS));                    // + 10s

so it needs over 20s. No testTimeout was set anywhere in the repo, so Jest's 5s default
applied and the test was killed mid-sleep every time:

✕ light widget matches baseline (5045 ms)
  Test timed out after 5000ms: hCaptcha theme rendering light widget matches baseline
  Pending promises at timeout: 1

The second case never ran (○ skipped), so neither baseline has actually been compared in
months.

This sets testTimeout: 60000 — 20s is the floor, the rest is headroom for a cold emulator
and the screenshot compare.

Follow-up worth doing separately

The fixed setTimeout(10000) settle is a guess: too slow locally, too fragile on a loaded
runner. Driving the fixture off the component's readiness signal instead would make each case
wait exactly as long as it needs and cut ~20s per case. Left out here to keep this PR to the
one-line unblock, since changing when the screenshot is taken may require regenerating the
baselines.

🤖 Generated with Claude Code

CAMOBAP and others added 2 commits October 5, 2026 00:18
Each case waits up to 10s for the WebView to load and then sleeps another
10s before screenshotting, so it needs more than 20s. No testTimeout was
configured anywhere, so Jest's 5s default applied and the first test was
killed mid-sleep every run - the suite has been red on master since at
least 2026-08-16.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The previous commit put testTimeout in jest.harness.config.mjs, which has
no effect. @react-native-harness/jest resolves it as

  session.config.testTimeout ?? projectConfig.testTimeout ?? globalConfig.testTimeout

and session.config is the rn-harness config, whose schema declares
testTimeout with .default(5000). Being a Zod default it is always
populated, so the first branch always wins and the Jest value is never
consulted - CI still timed out at exactly 5000ms.

Move it to rn-harness.config.mjs next to bridgeTimeout.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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