What are the possible solutions to delivering performance and stability for Playwright tests under real-world scenarios?

Discussions
, ,
1

So, would you rather:

Put more reliance on locator.waitFor()?

Use custom wait conditions (page.waitForFunction)?

Add retrials with test.retry()?

Create helper utilities for “waiting for page readiness”?

Or… just block those tests and focus on exploratory testing for such flows?

Really curious to learn how you guys approach these flaky-but-real UI patterns in your projects.

Let’s make tests smarter rather than slower! :rocket:

Thanks much, and happy testing! :heart:

2

In a perfect world, if our automation framework highlights “jankiness” the preferred outcome is that we fix it. However, we don’t live in a perfect world!

I have a preferred hierachy for waiting steps:

  1. No waiting where possible.
  2. Wait for visibility: e.g., waiting for a loading spinner to disappear, or for an interactable element to appear
  3. Wait for an API request: Either to resolve, or to fire.
  4. Network idle: It’s a nice catch-all, but I’ve found it behaves inconsistently across environments.
  5. Expicit wait: (waitForTimeout) this is dead last, because it will eventually fail.

I also prefer to have retries in my tests by default. It’s a crucial distinction in regression runs to know whether a test is flaky or actually failing.