بنقرة واحدة
dyaddeflake-e2e
Identify and fix flaky E2E tests by running them repeatedly and investigating failures.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Identify and fix flaky E2E tests by running them repeatedly and investigating failures.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | dyad:deflake-e2e |
| description | Identify and fix flaky E2E tests by running them repeatedly and investigating failures. |
Identify and fix flaky E2E tests by running them repeatedly and investigating failures.
$ARGUMENTS: (Optional) Specific E2E test file(s) to deflake (e.g., main.spec.ts or e2e-tests/main.spec.ts). If not provided, will prompt to deflake the entire test suite.Check if specific tests are provided:
If $ARGUMENTS is empty or not provided, ask the user:
"No specific tests provided. Do you want to deflake the entire E2E test suite? This can take a very long time as each test will be run 10 times."
Wait for user confirmation before proceeding. If they decline, ask them to provide specific test files.
Install dependencies:
npm install
Build the app binary:
npm run build
IMPORTANT: This step is required before running E2E tests. E2E tests run against the built binary. If you make any changes to application code (anything outside of e2e-tests/), you MUST re-run npm run build before running E2E tests again, otherwise you'll be testing the old version.
Run tests repeatedly to detect flakiness:
For each test file, run it 10 times:
PLAYWRIGHT_RETRIES=0 PLAYWRIGHT_HTML_OPEN=never npm run e2e -- e2e-tests/<testfile>.spec.ts --repeat-each=10
IMPORTANT: PLAYWRIGHT_RETRIES=0 is required to disable automatic retries. Without it, CI environments (where CI=true) default to 2 retries, causing flaky tests to pass on retry and be incorrectly skipped as "not flaky."
Notes:
$ARGUMENTS is provided without the e2e-tests/ prefix, add it$ARGUMENTS is provided without the .spec.ts suffix, add itFor each flaky test, investigate with debug logs:
Run the failing test with Playwright browser debugging enabled:
DEBUG=pw:browser PLAYWRIGHT_RETRIES=0 PLAYWRIGHT_HTML_OPEN=never npm run e2e -- e2e-tests/<testfile>.spec.ts
Analyze the debug output to understand:
Fix the flaky test:
Common fixes following Playwright best practices:
await expect(locator).toBeVisible() before interacting with elementsawait page.waitForLoadState('networkidle') for network-dependent testsawait page.waitForTimeout(300) (use sparingly)await expect(locator).toHaveScreenshot() options like maxDiffPixelRatio for visual testsIMPORTANT: Do NOT change any application code. Assume the application code is correct. Only modify test files and snapshot baselines.
Update snapshot baselines if needed:
If the flakiness is due to legitimate visual differences:
PLAYWRIGHT_RETRIES=0 PLAYWRIGHT_HTML_OPEN=never npm run e2e -- e2e-tests/<testfile>.spec.ts --update-snapshots
Verify the fix:
Re-run the test 10 times to confirm it's no longer flaky:
PLAYWRIGHT_RETRIES=0 PLAYWRIGHT_HTML_OPEN=never npm run e2e -- e2e-tests/<testfile>.spec.ts --repeat-each=10
The test should pass all 10 runs consistently.
Summarize results:
Report to the user:
Commit any uncommitted changes, run lint checks, fix any issues, and push the current branch.
Root-cause flaky or failing E2E tests from a specific CI run by downloading and analyzing the Playwright HTML report (traces, screenshots, errors). Use this when given a GitHub Actions run URL and asked to investigate failures. Diagnose from report artifacts first, then rebuild and rerun the affected E2E tests locally after making fixes.
Fix failing CI checks and GitHub Actions on a Pull Request.
Read all unresolved GitHub PR comments from trusted authors and address or resolve them appropriately.
Automatically gather flaky E2E tests from recent CI runs on the main branch and from recent PRs by wwwillchen/keppo-bot/dyad-assistant, then deflake them.
Promote the latest pre-release to a stable release by creating a release branch, bumping the version, and pushing.