DEV Community: Daniel Reade

Are AI Test-Generation Tools Actually Worth It Yet?

Daniel Reade — Wed, 15 Jul 2026 12:57:33 +0000

Most teams do not buy test-generation tools because they love tests. They buy them after a sprint where a small checkout change breaks five unrelated flows, nobody catches it in review, and the team spends half a day tracing a bug that a decent regression test would have found in minutes. That is the real pitch: less drift, fewer blind spots, and less time writing setup code by hand. The harder question is whether current AI tools can deliver that without filling a repo with brittle noise.

Where AI test generation already helps

The strongest use case is not full test authoring. It is draft generation around obvious seams. Give a model a controller, a service boundary, and a couple of input shapes, and it can often produce a first pass that saves thirty minutes of setup. For a Java team working with mocks and fixtures, that matters. A developer who used to spend the first hour of a task wiring test objects can now start from generated scaffolding, then trim and tighten.

That is a narrower promise than the marketing copy, but it is a useful one. Teams exploring how AI is being applied to automate testing workflows usually get the best return when they keep the tool close to repetitive work: fixture creation, edge-case suggestions, and parameterized input expansion. Those are annoying jobs, and they are easy to review.

There is another practical win. Generated tests can expose gaps in naming and structure. If a model keeps producing confusing assertions around one module, the module may be the problem. The code may have too many hidden dependencies or side effects that even a machine struggles to isolate. In that sense, the tool acts like a rough mirror. It does not just produce tests. It reveals where testability has already been neglected.

The quality problem is still real

A generated test that passes is not automatically a good test. This is the central problem, and it is why many senior engineers remain cautious. Current tools often optimize for syntactic completion instead of behavioral intent. They can produce a green checkmark while asserting almost nothing important.

Picture a payment method validator with eight branches: expired card, missing CVV, unsupported region, malformed token, and a few happy-path variations. A weak model may generate ten tests, but seven only verify that a method returns a non-null response. That looks like coverage. It is not meaningful protection. The test file grows, CI slows down, and the team gains very little signal.

This is where core concepts and levels of software testing still matter more than the tool itself. Unit tests should isolate behavior. Integration tests should verify boundaries that matter. Regression suites should protect known failure points. If a team cannot explain what a test is meant to catch, AI will only automate confusion faster. Good testing still begins with risk selection, not output volume. The repo does not care how quickly weak tests were produced.

The best results come from constrained generation

The tools look far better when the target is tightly scoped. Ask for a full suite across an unfamiliar codebase and the output often turns generic. Ask for tests around one pure function with clear inputs and expected failures, and results improve fast. Constraint is doing most of the work.

This is why tools such as an automated JUnit test generator for Java projects remain relevant in the conversation. They come from a world where generation is bounded by method signatures, search strategies, and measurable goals rather than open-ended prompting. Modern AI layers can be useful on top of that, especially for readability or cleanup, but the older lesson still holds: narrow the target and inspect every assertion.

A practical workflow looks like this. A developer selects one utility class of maybe 150 lines, asks for edge-case candidates, reviews the proposed cases, then keeps only the tests that express a business rule or a plausible failure mode. That is manageable. Letting a bot spray 200 tests across a module with network calls, caching behavior, and hidden time dependencies is how teams end up deleting half the output a week later.

What practitioners are arguing about

The debate has moved past whether generated tests are possible. Now the argument is about trust. In practical testers debating whether AI-generated tests are "good enough", the recurring pattern is cautious optimism from people using AI as an assistant, not as a replacement for judgment. That distinction matters. The tool is acceptable when it accelerates known work and suspicious when it claims to remove thinking from the loop.

The skeptical side has a strong case too. In a critique arguing AI-generated tests can create false confidence, the concern is familiar to anyone who has inherited a noisy suite: lots of assertions, little intent, poor maintainability. A generated test can look polished enough to survive code review while still missing the branch that actually breaks production.

So where does that leave a team lead deciding whether to adopt one of these tools? The right question is boring and useful: what failure mode is this supposed to reduce? If the answer is setup time on repetitive units, fine. If the answer is “better overall quality,” that is too vague to manage. Tools earn their keep when the expected gain can be checked in a pull request and felt during incident review.

Conclusion

AI test-generation tools are worth using when the bar is set correctly. They can save time on repetitive scaffolding, surface missed edge cases, and help teams move faster through low-risk test authoring. They still struggle with the part that matters most: choosing assertions that protect real behavior instead of decorating a codebase with busywork.

That makes the adoption decision less dramatic than vendors suggest. A team does not need to choose between full trust and total rejection. It needs a review standard. Keep generated tests if they express a clear rule, fail for an understandable reason, and remain cheap to maintain after the original prompt is forgotten. Drop the rest without sentiment.

The useful framing is simple. These tools are junior contributors with unnatural speed and uneven judgment. Teams that treat them that way can get real value now. Teams that mistake output for coverage will pay for that confusion later.

Taming Flaky Automated Tests For Good

Daniel Reade — Wed, 08 Jul 2026 17:47:18 +0000

A flaky test usually reveals itself at the worst possible moment: the build is green on one commit, red on the next, and green again after someone hits rerun. That pattern wastes more than CI minutes. It trains teams to doubt the signal from the suite, then to ignore failures that may actually matter. Once that habit sets in, shipping slows down because nobody trusts the line between a real regression and random noise.

Start by classifying the failure mode

Teams often call every intermittent failure "flaky," but that label is too broad to fix anything. A timeout during a browser click, a test that passes only in parallel runs, and an assertion that fails near midnight are different classes of problems. Treating them as one bucket leads to generic cleanup work that never lands.

A useful first pass is to tag failures by observable behavior. For example, create categories like timing, shared state, test data drift, environment mismatch, and nondeterministic assertions. In a suite of 800 tests, even a rough spreadsheet can surface patterns fast. If 25 failures in one week all involve delayed page rendering after an API call, the next step is obvious. If another cluster appears only when tests run on Linux workers, that points somewhere else entirely. The point is to reduce mystery.

This is where understanding flaky tests and mitigation strategies helps because it frames flakiness as a test-quality problem rather than simple bad luck. Pair that with core principles of software testing and test design, and the work becomes less emotional. Engineers stop arguing about whether a test is "probably fine" and start asking what input, dependency, or assumption is moving under it.

Remove hidden sources of nondeterminism

Many flaky tests are self-inflicted. They pull live time from the system clock, depend on randomized ordering, reuse the same user account across workers, or assume a database starts empty. All of those choices can work for weeks, then fall apart when parallelism increases or CI agents get slower.

The fix is rarely glamorous. Freeze time in code paths that compare timestamps. Seed randomness so the same execution path can be reproduced. Generate test data with unique IDs per run, then clean it up in a predictable way. If a suite provisions one temporary account for 40 parallel tests, expect collisions around password resets, profile edits, or background jobs. Give each worker isolated state and most of that noise disappears.

Practical test automation practices to reduce flakiness matter here because automation is not just about coverage. It is also about repeatability. A browser test that clicks a button before the app has settled is not fast, it is fragile. A service test that assumes queue processing finishes within 300 milliseconds is not precise, it is optimistic. Stability comes from controlling inputs and waiting on meaningful signals, such as a completed network response, a visible state change, or a known event in the log stream.

Retries hide symptoms when they replace diagnosis

Retries have a place, but only as a short-term containment tool with clear rules. A single retry can help absorb a known infrastructure blip, such as a worker losing network for a moment. The problem starts when teams use reruns as the main strategy. Then the suite stays nominally green while the underlying fault keeps spreading.

Picture a test that fails one run out of ten because it reads from an eventually consistent search index too soon. Add two retries and the pipeline may look healthy. The defect is still there. Engineers now spend less time seeing the issue, which means they spend less time fixing it. Later, another test hits the same index and the suite becomes noisy again. The retry bought quiet, not reliability.

That is why why retries alone don't solve flaky test problems is a useful framing. Retries should produce evidence. Log the first failure, count retry rates per test, and set a threshold where repeated flakes trigger quarantine or mandatory repair. If a test needed a retry in 7 of the last 20 runs, that is not a healthy pass. It is debt with a green badge.

Build an ownership model for flaky test debt

Flaky tests persist when everybody complains and nobody owns the repair loop. The suite becomes a shared nuisance instead of a maintained system. Ownership does not mean one unlucky person fixes every unstable test. It means the team has a defined path from detection to resolution.

One workable model is to assign ownership at the service or feature boundary. If checkout tests are unstable, the checkout team gets the alert, the failure history, and the authority to quarantine a test for a short period. Put a time limit on that quarantine. Seven days is concrete enough to create pressure without forcing rushed patches. Also track the cost. If one quarantined test blocks confidence in a release-critical path, that should be visible in sprint planning, not buried in CI logs.

This is where community approaches to managing flaky test debt and ownership can be useful, especially for teams that have normalized red builds. Good ownership turns vague frustration into routine maintenance. Someone sees the alert. Someone investigates the last ten failures. Someone either fixes the root cause or removes a test that no longer earns its runtime. Without that loop, flakiness becomes culture.

Make the suite observable enough to debug quickly

A test that fails without context invites guesswork. A test that fails with timing data, screenshots, network traces, and environment details usually gets fixed faster. Observability is what turns an intermittent problem into an actionable one.

For UI tests, capture the DOM snapshot at failure, a screenshot, browser console output, and the sequence of awaited conditions. For API and integration tests, log request IDs, dependency response times, queue lag, and fixture versions. Keep the logs structured enough that a maintainer can compare two failing runs side by side. If one failure took 14 seconds waiting for a job and another took 200 milliseconds before asserting stale data, they are likely different bugs wearing the same mask.

The investment pays back quickly. A team with 50 daily CI runs does not need perfect telemetry for every test, but it does need enough evidence to avoid blind reruns. The goal is simple: when a failure appears, the first person looking at it should be able to form a real hypothesis in two minutes. That is how a flaky suite stops feeling haunted and starts acting like software again.

Conclusion

Flaky tests are rarely random in the strict sense. They are systems telling you that timing, state, isolation, or visibility is weaker than the team assumed. The fastest way out is to stop treating each red build as a one-off annoyance. Classify failures, remove nondeterministic inputs, keep retries on a short leash, and make ownership explicit. Then add enough runtime evidence that debugging starts from facts instead of superstition.

There is a deeper payoff here. A trustworthy test suite changes how a team ships. Reviews move faster, releases feel less ceremonial, and engineers spend less energy negotiating whether a failure counts. That trust is hard to earn once the suite has gone noisy. It is still worth rebuilding, because every stable test becomes a small contract the code can actually keep.

The Page Object Model, And When To Skip It

Daniel Reade — Wed, 01 Jul 2026 15:37:30 +0000

A flaky UI suite usually does not fail because the browser is hard. It fails because the test code slowly turns into a second product with its own architecture, naming debates, and maintenance debt. The Page Object Model grew popular for a reason: once a suite passes a few dozen browser tests, selectors spread everywhere, login flows get copied, and one small button rename can break six files at once.

Why Page Objects Became the Default

Page Object Model, usually shortened to POM, solves a plain problem: too many tests know too much about the page. When a checkout test directly references #email, .submit-btn, and a coupon modal selector inside the same spec file, the test becomes brittle in a very practical way. Change the checkout form structure, and every test that touches it needs edits.

That is why teams building browser suites with tools like why Selenium is used for browser automation and how POM relates adopted page classes so widely. A CheckoutPage object can hold selectors, helper methods, and workflow actions in one place. A team with 40 regression cases across sign-in, cart, and payment flows often sees this pay off fast. Rename one selector in the page object, and half the suite survives untouched.

There is also a design argument behind it. POM borrows from the broader idea that code should hide implementation details behind stable interfaces, a point covered in principles for choosing reusable software design patterns. If the test says checkout.applyCoupon() instead of clicking through four nested elements, the intent is easier to read. The benefit is real, especially when the suite is maintained by several engineers over months rather than one person over a sprint.

Where POM Starts to Hurt

The trouble begins when page objects become a reflex instead of a choice. A modern front end rarely behaves like a neat stack of pages. It has drawers, embedded widgets, reusable cards, multi-step forms, and state that appears only after an API response. Stuffing all of that into giant HomePage, DashboardPage, and SettingsPage classes can create an awkward abstraction layer that mirrors file names more than user behavior.

Picture a test suite with 25 Playwright specs and 18 page object files. The DashboardPage class has methods for opening filters, checking metrics, dismissing banners, exporting reports, and editing profile settings because those controls all exist somewhere on the same route. Now the object is not protecting complexity. It is collecting it. New contributors have to jump between spec and object just to learn where a single click lives.

This is where the core purpose of how test automation works and when to automate UI tests matters. UI tests already cost more than service-level checks. If the abstraction layer adds another maintenance surface, the suite gets slower to change without becoming more reliable. The hard question is not whether POM is good or bad. The hard question is whether the page object removes duplication that actually exists, or whether it creates a framework before the suite has earned one.

What Modern Tools Changed

Playwright and similar frameworks shifted the tradeoff because they already ship with stronger primitives than older browser tools. Locators are more expressive, waiting behavior is built in, and test fixtures can manage setup without as much handwritten plumbing. A short test can stay readable even when it talks to the page directly.

That is why you now see arguments like discussion arguing Playwright often eliminates the need for Page Object classes. The point is not that structure no longer matters. The point is that a lot of historical POM boilerplate existed to compensate for weak ergonomics in older tooling. When a spec can say page.getByRole('button', { name: 'Save' }) and rely on sane waiting, a thin helper may be enough.

Take a common case: a login helper, an authenticated fixture, and two small component helpers for a date picker and a modal. That may cover most reuse in a medium suite. Building full page classes for every route can feel tidy at first, but it often buries intent under ceremony. The better abstraction is the one that makes the next failing test easier to fix.

When Skipping POM Is the Smarter Call

Skipping POM makes sense when tests are short, the application uses stable semantic selectors, and most reuse happens around state setup rather than page interaction. In many teams, the bigger source of repetition is not clicking the same button. It is creating the same account, seeding the same cart, or forcing the same permission state before the browser even opens.

That is the idea behind conversations like thread on whether API-based state setup makes Page Object abstractions unnecessary. Imagine a suite for a subscription app. Instead of navigating through signup, email confirmation, plan selection, and onboarding in every test, a fixture creates a user through an API call and stores auth state once. Each spec can land directly on the scenario it cares about. In that setup, a heavy SignupPage object adds little value because the flow rarely appears in tests.

Skipping POM also helps when the UI is highly component-driven. A DateRangePicker helper used in six screens is often more useful than six page classes that each wrap the same widget differently. Direct locators plus a few focused helpers keep the structure close to the real source of reuse. That makes failures easier to trace when the product team ships fast.

A Better Rule Than “Always Use POM”

The useful rule is simpler: abstract around volatility and repetition, not around every route in the app. If one modal appears in eight flows, extract it. If an address form has the same fields across admin and checkout screens, give it a helper. If a page is touched by one test and has five selectors, leave it inline until duplication shows up twice and starts to bite.

This keeps architecture proportional to the suite. A 12-spec smoke pack does not need the same shape as a 400-spec cross-browser regression suite. One team may do well with classic page objects because its product is route-heavy and its engineers rotate often. Another team may prefer fixtures, component helpers, and direct locators because most tests are narrow and setup lives in APIs. The right choice depends on where maintenance time is actually going each week.

Conclusion

The Page Object Model is still useful, but it is no longer the automatic answer many teams inherited from older browser stacks. Good test architecture should reduce the cost of change. That cost shows up in very ordinary places: finding the right selector, updating setup logic, tracing a flaky assertion, or onboarding the next engineer who has to debug a failure at 8 a.m.

If page objects make those jobs easier, use them. If they turn a small suite into a mini framework with classes nobody enjoys touching, skip them and keep the code closer to the test. Modern automation tools reward smaller abstractions, especially when fixtures and API setup remove most of the repetitive work before the UI even loads. The strongest teams are usually the ones willing to prune patterns that once made sense, then stopped paying rent.

Writing your first end-to-end test in Playwright

Daniel Reade — Fri, 26 Jun 2026 06:30:20 +0000

The first end-to-end test usually feels bigger than it is. A new project, a browser opening and closing, selectors that might break tomorrow, and a quiet suspicion that "real" engineers must have a cleaner way to do it. They do not. Most people start with one useful path, make it pass, then spend the next few runs learning what should have been obvious from the start.

Pick One User Journey and Keep It Small

A first test should cover a path a real user takes in under a minute. Login is the classic choice, but only if the app actually depends on authentication. A product search, a cart add, or a form submission can be better because the result is visible and easy to verify. The point is not to "cover the app." The point is to prove that the browser can drive one important flow from start to finish without hand-holding.

That sounds basic, but beginners often reach for too much. They script sign-up, email verification, profile setup, billing, and logout in one file, then wonder why every failure takes ten minutes to diagnose. A tighter start is a six-step path: open homepage, click sign-in, fill two fields, submit, wait for dashboard, verify one heading. That gives enough moving parts to learn navigation, selectors, waits, and assertions.

If the broader structure of testing still feels fuzzy, reviewing essential software testing concepts for end to end tests helps frame what this layer is meant to catch. End-to-end tests sit near the top of the stack. They are slower than unit checks, more exposed to UI changes, and valuable because they exercise the system the way a user does.

Set Up the Test Like a Reader Will Maintain It

A first Playwright file should be readable even after two bad weeks away from the codebase. That means clear naming, one scenario per test, and setup that stays close to the behavior. A lot of early pain comes from abstraction added too soon. If a selector is used once, keep it inline. If a helper hides five browser actions, ask whether the helper saves time or hides the thing that failed.

A simple structure works well: open the page, perform the action, verify the result. In practice, that might look like visiting /login, filling email and password, clicking submit, then checking for a visible account panel. If login requires test data, create a single known account for local runs rather than generating fresh users every time. Stable inputs make debugging less theatrical.

For people just getting oriented, the overview of Playwright and its core features is useful because it explains why the tool feels faster than older browser automation setups. Auto-waiting matters. Built-in locators matter. Cross-browser support matters too, though first tests should run in one browser until the flow is trustworthy.

A good first milestone is boring: one file, one path, one assertion that means something.

Use Locators and Assertions That Survive Real UI Changes

The first brittle Playwright test usually breaks because it targets the wrong thing. A CSS chain copied from devtools may pass today and explode after the next layout tweak. Better locators describe what the user can perceive: a button by role and name, an input by label, a heading by text, a form control by placeholder if nothing else exists.

That approach changes the maintenance cost. Suppose a checkout button moves from the sidebar to a sticky footer. A selector like div.wrapper > div:nth-child(2) button.primary dies instantly. A locator aimed at a button named "Checkout" often keeps working because the meaning stayed the same while the layout moved around it.

Assertions should also match the user outcome. After submitting a form, checking that the URL contains /dashboard can help, but a visible heading or account menu is usually a stronger signal. If a user would say "I know I'm logged in because I can see my account area," your test should verify something equally grounded.

If you want to see how working developers talk through these choices, engineers discuss practical approaches to writing Playwright tests in a way that feels closer to day-to-day practice than polished tutorials often do.

Treat Waiting, State, and Test Data as the Real Work

Most first-test frustration is not about syntax. It is about timing and state. The page loads before the data does. A click succeeds before the UI updates. A previous run leaves behind a user session and the login screen never appears. This is where new testers learn that "works on my machine" can happen inside automation too.

Playwright helps by waiting for elements to be actionable, but it cannot guess every business-level condition. If a report table takes a second to populate, verify that a specific row or empty-state message appears rather than sleeping for an arbitrary timeout. A hard wait of five seconds is easy to write and expensive to keep. Ten tests using the same habit can add almost a minute of dead time to a run.

State control matters just as much. Run each test with a known starting point. That can mean clearing storage, using a fresh browser context, or logging in through setup code and landing directly on the target page. The discussion around how system testing relates to end to end testing is useful here because it highlights the difference between validating a whole integrated system and checking a smaller behavior inside it. Your first test does not need to prove every dependency at once.

Expect Refactoring After the First Passing Run

A passing test is the start of the work, not the finish line. Once the path succeeds a few times, patterns become obvious. Repeated login steps should move into setup. Selectors that looked fine during the first run start to smell when copied into a second file. Screenshot and trace output becomes more useful after the first confusing failure than it ever was during the happy path.

This is also the point where many developers begin building a small framework around Playwright. That can be healthy if the extra structure solves a repeated problem. A page object for a noisy checkout screen makes sense after the third test touches it. A giant folder tree with base classes, utility layers, wrappers, and custom runners before test two usually creates more ceremony than value.

The most grounded advice often comes from people who just went through the messy part. In developer shares their first Playwright automation framework, you can see that tension clearly: structure is helpful, but only after the raw test cases reveal what should be extracted.

Conclusion

A first end-to-end test earns its value by teaching boundaries. It shows what the browser can verify, where the app is flaky, and how much hidden setup sits behind a "simple" user action. That lesson matters more than the single green checkmark. Teams that learn it early tend to write fewer oversized tests, choose stronger assertions, and treat test data as part of the product surface rather than background plumbing.

The smart next step is not to multiply test count as fast as possible. It is to make one test dependable, then add a second path that covers a different risk. If the first file proved login works, the next one might prove a user can complete a purchase or submit a request. After that, patterns worth abstracting reveal themselves on their own. Good Playwright suites usually grow from repeated evidence, not from grand design.

Writing your first end-to-end test in Playwright

Daniel Reade — Wed, 24 Jun 2026 12:26:30 +0000

Pick One User Journey and Keep It Small

Set Up the Test Like a Reader Will Maintain It

A good first milestone is boring: one file, one path, one assertion that means something.

Use Locators and Assertions That Survive Real UI Changes

Treat Waiting, State, and Test Data as the Real Work

Expect Refactoring After the First Passing Run

Conclusion

Selenium vs Playwright vs Cypress: an honest 2026 take

Daniel Reade — Mon, 22 Jun 2026 05:30:21 +0000

Most teams do not choose a browser testing tool because of a clean technical evaluation. They choose it after a painful week: flaky checkout tests, a CI pipeline that suddenly takes forty minutes, or a new app that mixes tabs, popups, file downloads, and API-heavy pages in ways the old setup never handled well. That is why the Selenium versus Playwright versus Cypress debate still matters in 2026. The useful answer is less about winners and more about fit under real constraints: team skill, browser coverage, debugging speed, and how much test instability a team can tolerate before confidence collapses.

What teams are really optimizing for

Browser automation choices are rarely about raw feature checklists. A team with six engineers shipping a React dashboard has different needs from a bank maintaining fifteen older internal apps, some of them still carrying brittle workflows inside legacy browsers and custom auth steps. The first team wants fast feedback, simple setup, and traces that show exactly why a selector failed. The second team often cares more about broad compatibility and long-term vendor neutrality.

That is where Selenium still earns respect. Selenium's history, components, and WebDriver API help explain why it remains deeply embedded in enterprise testing stacks. It fits organizations that already have large suites, custom frameworks, grid infrastructure, and engineers who understand browser drivers at a low level. Replacing that overnight can cost more than continuing to improve it.

Playwright and Cypress gained ground because they reduced friction. You can feel that difference on day one. A developer writes a login flow, runs it locally, gets auto-waiting behavior, useful error output, and fewer driver headaches. That kind of ergonomics changes adoption. Tooling choices become cultural choices fast, because the team will write more tests with the product that annoys them less.

Where Playwright feels strongest in 2026

Playwright has become the default recommendation for many greenfield web apps, mostly because it handles modern browser behavior without making the author fight the tool. Multi-tab flows, file uploads, downloads, permission prompts, and network inspection all feel like first-class use cases rather than edge-case add-ons. how Playwright works and its cross-language support is part of the appeal, especially for teams split across JavaScript, Python, Java, or .NET.

A concrete example helps. Picture a product team testing an onboarding flow with email verification, a payment step, then a PDF download. In older setups, each handoff can become a timing problem. In Playwright, the workflow tends to stay readable: wait for the popup, assert the URL, inspect the download event, capture a trace when the CI run fails. That shortens debug loops more than any benchmark chart will show.

It also fits the way many teams now work. Product engineers often own at least some end-to-end coverage, not just QA specialists. When the same person writes UI code in the afternoon and a regression test before leaving, good defaults matter. That practical pull shows up in community conversations like developers weighing whether to switch from Selenium to Playwright. The migration question keeps coming up because the daily writing experience is hard to ignore.

Why Cypress still has loyal users

Cypress remains attractive for one simple reason: when it fits your app, it is pleasant to use. The runner is approachable, local debugging is often excellent, and front-end developers can get productive quickly. For a single-page application with stable routes, predictable network calls, and a team working mostly in JavaScript, Cypress can still be a very comfortable place to build confidence.

Its tradeoffs are also clearer now than they were a few years ago. Cypress test runner, architecture, and limitations matter more once a suite expands beyond straightforward app flows. If your product opens a second tab during OAuth, relies on browser contexts that need strict isolation, or includes file handling that must mirror user behavior closely, those constraints show up quickly. A ten-test suite can feel elegant. A four-hundred-test suite sometimes exposes every design assumption the framework made early on.

That does not make Cypress obsolete. It makes it specific. Teams with strong component testing habits, a front-end-heavy codebase, and a desire for a tight in-browser development loop may still get excellent value from it. The mistake is treating ease of first use as proof of long-term fit. Early comfort and later flexibility are not the same thing.

Selenium is older, but old is not the same as wrong

A lot of Selenium criticism is really criticism of aging test suites. That distinction matters. A brittle suite built over seven years with weak locator strategy, inconsistent waits, and too many UI-level assertions will be painful in any framework. Move that suite tool-for-tool into something newer and many of the same habits will survive the migration.

Selenium still makes sense when browser breadth is non-negotiable, when a company already runs parallel execution at scale, or when the stack around it is bigger than the library itself. Think of a QA group supporting twelve product surfaces with shared page objects, internal reporting, custom containers, and compliance review around every dependency update. In that setting, replacing the execution engine is one part of the cost. Retraining people and rebuilding trust is the bigger one.

The interesting 2026 question is not whether Selenium is modern enough. It is whether the team using Selenium has disciplined enough engineering practices to keep a large suite healthy. QA practitioners discussing Playwright, Selenium, and AI testing tools often circle back to this same point. Flakiness is usually an architecture problem before it becomes a brand-name problem.

The honest recommendation for most teams

If a team is starting fresh on a modern web app, Playwright is the safest default. It offers strong browser automation, useful debugging artifacts, and fewer setup frustrations than Selenium. It also handles more edge cases cleanly than Cypress for many end-to-end scenarios. That does not mean every team should migrate tomorrow. It means the burden of proof now sits with alternatives when there is no legacy to protect.

Choose Selenium when you already have meaningful investment, cross-browser depth that has been hardened over time, or language and infrastructure requirements that make continuity valuable. Choose Cypress when the team is front-end-led, the app shape aligns with its runner model, and rapid local iteration matters more than broad execution flexibility.

The worst choice is the one made from trend anxiety. A team with eighty reliable Selenium tests and a stable release process is in a better position than a team halfway through a fashionable migration with no ownership model. Tools do matter. The discipline around test design, fixture strategy, and failure triage matters more.

Conclusion

The strongest browser testing setup in 2026 is usually the one your team can keep trustworthy under release pressure. That shifts the decision away from hype and toward operational reality. How quickly can a failed test be explained? How often does a developer rerun a test before believing it? How expensive is a migration when the current suite already covers revenue-critical flows?

Playwright has the clearest momentum for new work because it reduces friction without asking teams to give up serious testing depth. Selenium remains viable where scale, history, and compatibility carry real weight. Cypress still belongs in the conversation when the app and team shape match its strengths.

A useful rule is simple: optimize for confidence per hour, not for framework prestige. The tool that helps a team write stable coverage, debug failures fast, and keep ownership close to the product will usually beat the one that looks strongest in a comparison chart.