5 Best Practices for Playwright E2E Testing

When looking for ways to automate end-to-end (E2E) testing, many teams choose Playwright. 

It’s generally a pretty good option, though, like any tool, what you get out of it will depend on how you use it.

Whilst we’re on the topic, we’d also encourage you to take a look at some Playwright alternatives. There are some issues that the platform doesn’t address. Given the advances in testing tech, it’s worth shopping around to see what else is on the market.

So, if you’re new to Playwright E2E testing, grab a pen (or open your Notes app) and jot down these tips. 

Five Best Practices for Playwright E2E Testing

1. Keep User Experience Central

E2E tests (in Playwright or anywhere else) are all about the user perspective. 

It’s tempting, from a practical point of view, to drift away from this and write tests that mirror the DOM structure. Avoid this, keep the focus on the user journey: 

• Can a user log in?
• Can they complete checkout?
• Can they update their profile?
• Does search return correct results?

This gives you better, more insightful results, and also encourages good test design. Tests that rely on structural details, such as nested CSS selectors or brittle class names, break easily, even where functionality hasn’t changed. 

Your Key Takeaways

• Choose role-based or text-based selectors
• Use data-testid attributes for stability
• Avoid selectors that depend on visual structure

This reduces flaky tests and the maintenance burden associated with them.

2. Isolate Tests and Eliminate Shared State

Shared state will kill your E2E test stability. Worst of all, it will do it quietly, so you pour frustrating amounts of time into figuring out what’s wrong before that final, head-to-desk moment when you figure out what it really was all along. 

In Playwright E2E testing, flaky tests often trace back to reused accounts, leftover data, and inconsistent session states. This reduces reliability significantly and also causes issues when running tests in parallel. 

Your Key Takeaways

Each test should:

• Create its own data
• Clean up after itself
• Run independently of other tests
• Use fixtures strategically, e.g., seeding unique users per test, resetting backend state via API
• Use fresh browser contexts for isolation

3. Use Smart Waiting Strategies (Avoid Arbitrary Timeouts)

One of the biggest advantages of Playwright E2E testing is its built-in auto-waits. Many teams ignore this and introduce unnecessary waitForTimeout() calls. Don’t be that team. 

WaitForTimeout introduces a significant stability risk. Playwright autowaits are condition-specific (“wait for this element to become visible to do X”). WaitForTimeout calls impose a fixed time limit (“wait for 10 seconds to do X”). This throws up all sorts of issues, including: 

• Tying test stability to an arbitrary time limit
• Slowing down test runs
• Masking real synchronization issues as timing failures

Key Takeaways

Use condition-based waits for speed and reliability of Playwright E2E testing. These could include waiting for an element to appear, waiting for navigation to complete, or waiting for a network response. 

4. Keep Tests Small and Purpose-Driven

Longer tests are difficult to maintain over time because they make debugging harder and slow down feedback loops. Results also provide less clarity, given the size of the test. 

For faster, more reliable Playwright E2E testing, break things down into more focused tests that validate a single business objective. These fail faster, are easier to debug, and scale much better in CI. 

Key Takeaways

Instead of one 100-step test covering everything, take a modular approach to Playwright E2E testing. Break tests down into individual user flows rather than lumping everything together, for example: 

• Login test
• Checkout test
• Profile update test
• Settings modification test
• Logout test
• ‘Delete account’ test
• Separate tests for each app functionality

5. Treat Your Playwright E2E Test Suite Like Production Code

Many teams write Playwright E2E testing scripts as if they’re temporary, but they rarely are. Do you really envisage writing the script again in the near future? 

If the answer is ‘no’, it’s time for some proper engineering discipline to kick in. Treat your test code like your production code and:  

• Use consistent folder structures
• Abstract repeated logic into helpers
• Version control test data
• Conduct code reviews on test PRs
• Track test metrics (failure rate, runtime, flakiness)

Additionally, set time aside for regular audits, remove obsolete tests, and refactor fragile ones to maintain efficiency and avoid unnecessary bloat. 

Key Takeaways

The more your Playwright E2E testing suite grows, the more it behaves like a second codebase. Without structure and good discipline, it can become an unwelcome source of technical debt.

The Hidden Inefficiencies of Playwright E2E Testing

Will these Playwright E2E testing best practices make everything more efficient? Absolutely. 

Will they eliminate any of these sources of friction for E2E tests completely? Probably not.  

This is because some limitations are hard-baked into Playwright as a piece of software and the model of testing it provides. Writing good tests will not solve this. 

Read more: How moving away from Playwright automation led to an 83% decrease in test generation and maintenance times for Mutiny

1. Manual Test Authoring Doesn’t Scale

Testing with Playwright is inherently reactive. Engineers are constantly chasing UI updates, and each new feature requires: 

• Writing new test cases
• Updating selectors
• Maintaining flows
• Refactoring when UI changes

This is a significant time cost, even with Playwright’s limited low-code tools. As your app expands, it’s just not sustainable. The only workable solution is relying on external QA, which introduces bottlenecks and inefficiencies of its own. 

2. Flakiness Is Reduced, Not Eliminated

Playwright’s auto-waiting and isolation improve reliability, but they don’t eliminate:

• Environmental inconsistencies
• Network variability
• Third-party service behavior
• Race conditions in dynamic apps

This means that even well-written tests can fail for reasons unrelated to actual product defects.

3. Tests Validate What You Expect, Not What You Missed

Traditional E2E automation works from predefined scripts; you test what you choose to test. But what about the things you miss, edge cases, regressions in unexpected areas, and the like? 

This isn’t exactly Playwright’s fault. Automation has, until this point, always been about verifying rather than exploring. But things are changing, and there are solutions out there that can take a more proactive, exploratory approach. 

4. Debugging Remains Manual and Time-Consuming

Interpreting failures, investigating logs, and inspecting trace artifacts, it all take time. With a trend towards smaller teams and tighter budgets, that’s the time you don’t have. 

And, as your test suite grows, this maintenance overhead grows with it. Playwright can’t help you with this. 

AI Testing Tools: A Better Alternative to Playwright E2E Testing

So, given these inefficiencies, why have we stuck with Playwright E2E testing all this time?  Simple: it was the best on the market at what it did. There was no better alternative out there. 

That’s changed. AI-driven testing platforms can offer so much more for teams. They aren’t just faster; they offer an entirely new approach to automated E2E testing that offers some pretty mindblowing efficiency gains. Here’s how. 

Read more: How Momentic customer Roo reclaimed over 200 engineering hours per quarter and reduced time spent maintaining flaky tests by 50%

Natural Language Test Creation

No more coding. You write what you want the test to do in plain English. The AI interprets this into a test and runs it for you. 

The simplicity is transformative; your engineers can test code as they go (less technical debt), it’s easier to shift left (better product quality), and testing is open to business and other non-technical stakeholders (greater organizational transparency, and less time on Teams explaining your results to Jason from Strategy). 

Self-Healing Selectors

Playwright E2E testing offers a range of selectors (role-based, text-based, label-based, placeholder/alt text, test ID)...so you’re not tied down to brittle X-Path or CSS options. 

However, AI testing tools can go one step better. Platforms like Momentic use intent-based locators that adapt to UI changes automatically and identify elements based on semantic meaning. Your maintenance workload is instantly hours lighter. 

Intelligent Failure Analysis

Instead of simply reporting “element not found,” advanced AI testing systems can:

• Diagnose root causes
• Identify whether a failure is flaky
• Explain likely regression sources
• Provide meaningful summaries

This shaves valuable time off of your team’s debugging workload, resulting in faster feedback loops and smoother, faster release schedules. 

Autonomous Test Exploration

AI agents can explore your app by themselves. So, whilst you verify what you know you want to test, you can also benefit from an autonomous digital coworker that: 

• Explores different user flows
• Identifies edge cases and unexpected states
• Suggests tests and highlights high-risk areas

This moves beyond reactive Playwright E2E testing toward something way more proactive; you anticipate issues in advance, so they don’t become a roadblock just before release. 

Continuous Adaptation

The best bit about AI testing tools is that they get smarter the more you test. 

AI tools continuously learn from application changes, historical failures, usage patterns, and UI evolutions to provide better, more accurate suggestions. 

8x Your Release Cycle With Momentic

You read that right. Our customer Retool implemented Momentic’s AI testing platform and started releasing 8x more frequently. 

If you’re looking for a faster, easier, and more modern alternative to Playwright E2E testing, why not book a demo? We’d love to see how we could help. 

Book a demo