Why Most Playwright Test Suites Fail (And How to Fix Yours)

The Dirty Secret: 80% of Test Suites Die Within a Year

Let me tell you something the conference speakers and tutorial creators will not say: most Playwright test suites are dead within 12 months of creation.

I am not guessing. I have watched it happen at four different companies, and I have been called in to diagnose it at dozens more. The pattern is always the same. A team gets excited about Playwright. They write 200 tests in the first month. The CI pipeline is green. Everyone celebrates. Then, slowly, things start to crack.

By month three, a handful of tests start flaking. By month six, developers are re-running the pipeline "just to get it green." By month nine, someone suggests disabling the flaky tests "temporarily." By month twelve, the suite is either abandoned entirely or has become a checkbox that nobody trusts — green or red, nobody cares anymore.

I have seen this cycle repeat so many times that I can now predict whether a test suite will survive just by looking at its folder structure for five minutes. The problems are structural, not technical. Playwright is an excellent tool. The teams using it are usually talented. The architecture is what kills the suite.

Here are the 7 mistakes I see in almost every failing test suite — and the architecture that prevents all of them.

Mistake 1: Testing UI Instead of Behavior

This is the most common mistake, and it is the most destructive. Teams write tests that check how the page looks instead of what the application does.

I reviewed a suite last year that had 47 tests checking CSS classes. Tests like "verify the submit button has the class btn-primary" or "verify the error message container has display: block." Every single one of those tests broke when the design team updated the component library. All 47. In one pull request.

The developers who wrote those tests were not incompetent. They were following patterns they had seen in tutorials and blog posts. The problem is that those patterns test implementation details — and implementation details change constantly.

Here is the difference in practice:

// This test breaks when CSS classes change
await expect(page.locator('.error-msg')).toHaveClass(/visible/);
await expect(page.locator('#submit-btn')).toHaveCSS('background-color', 'rgb(26, 46, 110)');
await expect(page.locator('.form-group')).toHaveCount(5);

// This test survives redesigns
await page.getByLabel('Email').fill('invalid-email');
await page.getByRole('button', { name: 'Submit' }).click();
await expect(page.getByText('Please enter a valid email address')).toBeVisible();

The first test checks CSS class names and DOM structure. It will break on every redesign. The second test checks what the user sees: fill an invalid email, click submit, see an error message. That test survives any redesign that preserves the same user experience — which is almost all of them.

The rule is simple: if a designer can break your test without changing any behavior, your test is wrong. Use Playwright's getByRole, getByLabel, and getByText locators. They test what users see, not how developers built it. For more on this philosophy, read the Playwright best practices for 2026 guide.

Mistake 2: No Architecture

Open the test folder of a failing suite and you will see something like this: 200 flat .spec.ts files in a single directory. No Page Object Model. No shared fixtures. No test data strategy. Every test file creates its own browser context, navigates to the login page, types credentials, and then does whatever it was actually supposed to test.

I call this the "copy-paste architecture." Developer A writes a test. Developer B needs to test something similar, so they copy Developer A's file, change a few lines, and commit. Now you have the same login flow duplicated in 80 files.

Then the login page changes. A new CAPTCHA is added. A field gets renamed. Someone has to update 80 files. They update 76 of them. The other 4 fail silently because nobody realized they existed. The CI goes red. Nobody knows why. Someone disables the 4 tests. Technical debt compounds.

A production-grade test suite needs at minimum: a Page Object Model for each major page, shared fixtures and hooks for authentication and setup, a test data strategy that does not depend on production databases, and a folder structure that mirrors the application's feature areas — not a flat dump of files. For a full walkthrough of building this from scratch, see how to build a Playwright framework from scratch.

Mistake 3: Ignoring Test Independence

This is the number one cause of flakiness, and it is not even close.

Tests that depend on each other — tests that must run in a specific order, tests that share state through a database, tests that assume a previous test created the right data — are a ticking time bomb. They work on your machine. They work in CI when the stars align. Then one test runs a fraction of a second slower and the whole chain collapses.

I once spent two full days debugging a suite where 12 tests passed individually but failed when run together. The root cause: Test 3 created a user. Test 7 modified that user. Test 12 deleted that user. But Playwright runs tests in parallel by default, so sometimes Test 12 ran before Test 7, and sometimes Test 7 ran before Test 3. The suite only passed when the tests happened to execute in the exact order they were written.

The fix is absolute: every test must be able to run in isolation, in any order, at any time. Each test creates its own data, performs its own actions, and cleans up after itself. If that sounds expensive, you are right — it requires investment in fixtures and test data factories. But that investment is what separates a suite that lasts from a suite that collapses.

Playwright's built-in fixture system makes this straightforward. Use test.extend() to create fixtures that provision fresh data for each test and tear it down after. It is more work upfront. It saves you hundreds of hours of debugging later. Read our flaky tests fix guide for the detailed implementation patterns.

Mistake 4: Copy-Pasting from Tutorials

I have a confession: tutorial code — including some I have written — is optimized for learning, not for production. Tutorials use TodoMVC because it is simple and familiar. They use hardcoded URLs because it keeps the example focused. They skip error handling because it distracts from the concept being taught.

The problem is not the tutorials. The problem is that teams copy these patterns directly into enterprise applications and expect them to scale. They do not.

TodoMVC has one page, five actions, and no authentication. Your production application has 50 pages, hundreds of user flows, three user roles, a staging environment with different data than production, and an API that sometimes takes 4 seconds to respond. The patterns that work for TodoMVC — flat files, hardcoded selectors, no abstraction — will buckle under that complexity within weeks.

Tutorials are the starting point, not the blueprint. Use them to learn the API, then build your own architecture that fits your application's specific complexity. That is exactly what separates senior automation engineers from people who know Playwright syntax.

Mistake 5: Over-Testing Happy Paths

Pull up any failing test suite's coverage and you will see a disturbing pattern: 95% of the tests verify that things work correctly. The login succeeds. The form submits. The item appears in the cart. The checkout completes.

Meanwhile, the production bugs your users report are all in the other 5%: what happens when the network drops mid-checkout? What happens when a user double-clicks the submit button? What happens when someone pastes a 10,000-character string into the search field? What happens when the session expires during a multi-step form?

Happy path testing is necessary but insufficient. The tests that actually prevent production incidents are the ones that verify failure modes: error handling, edge cases, timeout behavior, concurrent actions, and recovery flows.

Here is my rule of thumb for a production suite: for every 3 happy-path tests, write at least 1 negative test and 1 edge-case test. That ratio ensures you are covering the scenarios where real bugs live. Your users are creative in ways your happy-path tests will never anticipate — but your edge-case tests can get close.

Playwright makes negative testing surprisingly easy with network interception. You can simulate API failures, slow responses, and timeout scenarios without touching your backend. There is no excuse for a suite that only tests the sunny day.

Mistake 6: Treating AI-Generated Tests as Final

This one is new, and it is growing fast. With tools like Claude AI, teams can now generate 50 Playwright tests in an afternoon. The tests run. They pass. The team commits them and moves on.

Six weeks later, the suite is unmaintainable.

Here is what happened: Claude generates excellent first drafts. The locators are accurate. The assertions make sense. But the generated tests have no naming convention. They do not follow the team's POM structure. They duplicate setup code because each test was generated independently. They use different assertion styles because each generation session had slightly different context. They are, in effect, 50 individually correct tests that do not form a coherent suite.

AI makes it incredibly fast to create technical debt. That is not a criticism of the tools — it is a warning about the workflow. Claude generates the code. A human must review it, refactor it into the team's architecture, apply naming conventions, extract shared fixtures, and ensure it fits the existing test strategy.

The correct workflow is: generate with AI, review like a human, refactor into your architecture. Claude writes the first draft. You restructure it into your POM. You extract common fixtures. You rename tests to follow your conventions. The AI handles the tedious locator work. You handle the architectural decisions. Together, you move three times faster than either could alone.

Mistake 7: No CI Feedback Loop

The final mistake is the quietest killer. Teams set up Playwright in GitHub Actions or Jenkins. Tests run on every push. Results are published. And then... nobody looks at them.

I have seen teams where the CI pipeline had been red for three weeks straight and nobody noticed. The tests were running, the reports were generating, but the results disappeared into a void. Failed tests accumulated like unopened mail. By the time someone looked, there were 40 failures — too many to triage in a single sprint, so they were pushed to the backlog. And the backlog is where test failures go to die.

A test suite without a feedback loop is a test suite without a purpose. If nobody acts on the results, the tests are just burning CI minutes for nothing.

The fix requires both technical and cultural changes. On the technical side: set up Slack or Teams notifications for test failures, implement a failure budget (if more than 3 tests fail, the build is blocked), and generate visual HTML reports that make failures easy to diagnose. On the cultural side: treat test failures with the same urgency as production incidents. A failing test means either the application has a bug or the test needs updating — both require immediate action.

My rule: every test failure must be triaged within 24 hours. Fix the test, fix the app, or delete the test. "We will look at it later" is how suites die.

The Architecture That Survives: My Production Blueprint

I have spent years refining an architecture that prevents all seven of these mistakes. It is not complicated. It just requires discipline and structure from day one. Here is the blueprint.

Layer 1: Page Object Model

Every page or major component gets a POM class. Locators live in exactly one place. When the UI changes, you update one file. Every test that interacts with that page inherits the fix automatically. This directly prevents Mistakes 1 and 2. See the full Page Object Model tutorial for implementation details.

Layer 2: Fixture Isolation

Authentication, test data creation, and environment setup live in Playwright fixtures. Each test gets a fresh, isolated context. No shared state. No sequential dependencies. This kills Mistake 3 at the root. Our fixtures and hooks guide walks through every pattern you need.

Layer 3: Behavior-Driven Locators

The entire suite uses getByRole, getByLabel, getByText, and getByTestId exclusively. No CSS selectors. No XPath. No class-name queries. This makes tests resilient to redesigns and directly addresses Mistake 1.

Layer 4: Test Data Strategy

Tests generate their own data via API calls in fixtures, use that data for assertions, and clean up afterward. No dependency on seed databases. No "run this SQL script first" prerequisites. Each test is a self-contained unit that can run anywhere, anytime.

Layer 5: AI Generation + Human Review

Claude AI generates the initial test drafts using the MCP server for accurate locators. A human reviews every generated test, refactors it into the POM structure, extracts shared fixtures, and applies naming conventions before committing. This captures the speed of AI without the architectural debt of Mistake 6.

Layer 6: CI with Teeth

Tests run in GitHub Actions with parallel sharding. Failures trigger Slack notifications immediately. A failure budget blocks merges when more than N tests fail. HTML reports are uploaded as artifacts and linked in the Slack message. Every failure is triaged within 24 hours. This is the feedback loop that prevents Mistake 7.

This 6-layer architecture is not revolutionary. Every piece of it is standard practice in mature engineering organizations. The problem is that most teams skip layers 2 through 6 because they seem like overhead when you only have 10 tests. By the time you have 100 tests and need those layers, the cost of adding them retroactively is enormous. Build the architecture before you need it.

Frequently Asked Questions

Meet Your Instructor

Asim Noaman

Senior QA Automation Engineer & AI Testing Specialist

With years of hands-on experience building test automation frameworks for production applications, Asim specializes in combining traditional QA methodologies with cutting-edge AI tools. He has helped teams adopt Playwright and AI-driven testing workflows to ship faster with fewer bugs.

Udemy Instructor Published course author

Playwright + AI Expert Specialized in AI-powered QA

Production Experience Enterprise-grade frameworks

Connect on LinkedIn