If you work with Playwright, you may have faced flaky tests. A flaky test is one that sometimes passes and sometimes fails, even when nothing has changed in the code. This is often because of unstable locators (the way we find elements on a page).
To solve this, Playwright allows us to use smart fallback locators. These are backup locators that work when the main locator fails. Let’s understand how they work in simple terms.
What Are Smart Fallback Locators?
Normally, when you write a Playwright test, you use one locator like:
await page.click(‘#login-button’);
But what if the button’s ID changes to something else in production? Your test will fail.
With smart fallback locators, you can provide multiple locator options. If the first one fails, Playwright will try the next.
Example:
await page.locator(‘#login-button, text=”Login”‘).click();
Here:
-
First, it tries to find the button by ID.
-
If it fails, it looks for a button with text “Login”.
This makes your tests stronger and less flaky.
Why Are Fallback Locators Useful?
-
Reduce Flaky Tests – Tests don’t fail just because of a small locator change.
-
Save Debugging Time – Less time wasted fixing locator issues.
-
Better Test Stability – Works across different environments (staging, production, etc.).
-
Helps with Dynamic Apps – In modern apps, locators can change often.
Best Practices for Smart Fallback Locators
- Always keep the most stable locator first (like
data-testid). - Use visible text as backup.
- Avoid using too many fallback options (can slow down tests).
- Combine with auto-waiting features of Playwright.
// Without fallback (risky)
await page.click(‘#login-btn’);
// With smart fallback
await page.locator(‘#login-btn, text=”Sign in”, role=button’).click();
In the second example, even if the ID changes, the test can still find the button by text or role.
Conclusion
Smart fallback locators in Playwright are a simple but powerful way to reduce flaky tests. They let you give backup selectors so that your tests can still run even if the UI changes slightly.
By using them, you’ll spend less time fixing broken tests and more time building useful automation.
