DEV Community: Daniel Reade

Writing your first end-to-end test in Playwright

Daniel Reade — Wed, 24 Jun 2026 12:26:30 +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.

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.