Modern browser testing is no longer just about clicking a button and checking whether the next page loads.
Frontend applications now contain animated route changes, Shadow DOM components, dynamic validation, session refresh logic, AI-generated interfaces, visual transitions, and increasingly complex release pipelines.
At the same time, AI is making it easier to generate both application code and automated tests. That sounds like it should simplify testing, but it also creates a new problem: teams can produce more code and more tests without necessarily improving confidence in their releases.
I recently went through several articles that explore these problems from different angles. Here are some of the ideas that stood out.
A test can pass repeatedly and then fail when a layout shift causes the browser to recalculate the position of an element.
That is particularly frustrating because the selector may be correct and the element may technically exist. The failure happens because the page is moving while the automation is trying to interact with it.
This guide on debugging browser tests that fail when layout shifts trigger a reflow explains why these failures can be difficult to reproduce and what evidence is worth collecting.
CSS animations introduce a similar problem. With view transitions and animated navigation, a page may appear ready even though the browser is still changing its visual state.
The article How to Debug Browser Tests That Fail Only After CSS View Transitions or Animated Route Changes looks specifically at failures that happen during these transitions.
The important lesson is that waiting for an element to exist is not always enough. Sometimes you need to wait for the interface to become stable.
Most teams still treat automated tests as a binary signal:
That model is useful, but it becomes less reliable when applications and tests are changing quickly.
A passing test suite might still miss a visual regression, an untested AI-generated code path, or a risky frontend change that deserves additional review.
How to Build a Release Signal for Frontend Changes When Green CI Is Not Enough discusses how teams can combine test results with other forms of evidence instead of relying on a single green checkmark.
For AI-generated interfaces, the release decision may need to include screenshots, visual differences, risk indicators, and test evidence. This is explored further in How to Build a Release Gate for AI UI Changes Using Test Evidence, Screenshot Diffs, and Risk Signals. This does not mean every release needs a complicated scoring system. It means the release signal should reflect the actual risks of the application.
AI can generate a working frontend feature surprisingly quickly. It can also generate tests for that feature.
But generated tests often focus on the most obvious path. They may not cover interrupted workflows, existing user state, permission differences, session expiration, validation errors, or interactions with older parts of the application.
How to Review AI-Generated Frontend Pull Requests for Test Coverage Gaps Before Merge provides a useful way to think about these gaps during code review.
The goal is not to distrust every line of AI-generated code. It is to avoid confusing generated test volume with meaningful coverage.
The Playwright-versus-everything discussion is often reduced to features, syntax, and execution speed.
In practice, the correct choice depends heavily on what the team is testing and who will maintain the automation.
For example, testing web components introduces questions about Shadow DOM boundaries, slots, reusable components, and selectors that behave differently from those used in traditional pages. Endtest vs Playwright for Testing Web Components, Shadow DOM, and Slot-Based Layouts compares the two approaches in that context.
Maintenance is another major factor. A code-first framework can offer a great deal of flexibility, but the team must own the framework, integrations, debugging process, reporting, infrastructure, and long-term updates.
Endtest vs Playwright for Teams That Need Less Test Maintenance in Fast-Changing Frontends focuses more directly on that tradeoff.
There is also a useful comparison of mabl vs Playwright for teams choosing between an AI-assisted platform and a code-first browser automation library.
For checkout testing, the requirements can be different again. Redirects, conditional fields, dynamic totals, third-party payment pages, and changing validation messages can make a simple purchase flow surprisingly difficult to automate reliably. Endtest vs Cypress for Teams Testing Multi-Step Checkout Flows With Dynamic Validation and Redirects examines that narrower use case.
There is no universal winner across all of these comparisons. The better question is usually: which approach creates the least operational friction for this particular team?
A login test that enters an email and password is easy.
Testing the full authentication lifecycle is much harder.
Real applications may silently refresh access tokens, redirect users back to their previous location, require a second verification step, recover from an expired session, or behave differently when authentication partially succeeds.
Endtest Review for Teams Testing Login, Session Refresh, and Multi-Step Recovery Flows looks at the practical requirements behind these scenarios.
Internal tools have similarly complicated workflows. A request may need to move through several users, roles, and approval states before it is complete.
Endtest Review for Teams Testing Multi-Step Approval Flows in Admin and Internal Tools covers the challenges involved in automating those processes.
These are the kinds of tests where setup, test data, user permissions, and cleanup often require more work than the visible browser interactions.
Some AI applications do not produce a simple deterministic result.
They generate a recommendation, draft, action, or decision that must be reviewed by a human before the workflow continues.
Testing that process requires more than checking that a button exists. The test may need to validate the generated output, verify the approval state, simulate rejection, and confirm what happens when the AI response is delayed or incomplete.
The Endtest Buyer Guide for Teams Testing AI-Powered Browser Workflows With Human Approval Gates discusses what teams should evaluate when choosing an automation approach for these workflows.
This will probably become a more common testing pattern as AI features are added to existing SaaS products.
AI testing is becoming an increasingly broad category.
It can mean:
These capabilities solve different problems and have different costs.
What Is the Best Way to Automate Tests with AI? provides a useful overview of the main approaches and the tradeoffs between them. AI can accelerate test creation, but test creation is only one part of automation. Teams still need reliable execution, understandable results, maintainable workflows, and a process for deciding which failures matter.
Playwright MCP adds another interesting dimension by allowing AI agents to interact with browsers through Playwright.
The Playwright MCP Guide covers how this approach works, what it can be used for, and where it fits alongside traditional Playwright tests.
I also recently published a video comparing Playwright and Selenium in the current testing landscape:
The Playwright-versus-Selenium debate is often framed as a battle between an old tool and a new tool. The reality is more nuanced.
Both can automate browsers. The larger differences usually involve architecture, ecosystem compatibility, team experience, maintenance expectations, and how much supporting infrastructure the team is prepared to build.
The common thread across all of these topics is that browser automation libraries are only one part of the solution.
A reliable testing process also depends on:
AI can help with many of these areas, but it does not eliminate the need to design the overall system carefully.
The teams that get the most value from automation are rarely the teams that generate the largest number of tests. They are the teams that create a dependable feedback loop and keep it useful as the product changes.