Flat illustration of a test pyramid with a narrow top, a browser window with three passing tests and a trace bar, plus an eye and a remote control with a record button
Back to blog
PlaywrightE2E TestingTest Pyramid

Playwright Talks Recap: Why E2E Testing Grows Bottom-Up

Sven HennessenEvents

TL;DR

  • Hardly anyone disputes that quality matters and that Playwright helps. But E2E tests only caught on widely where the team itself got them started.
  • E2E tests remain expensive to write, maintain and keep stable, AI or not. So respect the test pyramid and use them sparingly, for the critical scenarios.
  • With MCP and the CLI, Playwright has become a remote control for coding agents: only by looking at the rendered browser can an agent tell whether its UI really works.

In November 2025 I spoke about Playwright at WebWorker Saar, and in September 2026 at the .NET User Group Karlsruhe. In the year between them, not much changed about how widely E2E tests are adopted, but a lot changed about the role Playwright plays. A look back at two evenings, one failed demo, and why a good testing culture almost always starts inside the team.

In November 2025 I was at WebWorker Saar, hosted by Meta-Level Software AG in Saarbrücken, talking about Playwright: E2E tests, Testcontainers, GenAI and MCP, and why it all suddenly fits together. Almost a year later, Playwright was on the agenda again, this time at the .NET User Group Karlsruhe. Two evenings, two audiences, and one observation that held true both times.

Sven Hennessen in a vensas hoodie next to a large screen showing the title slide of the Playwright talk at Meta-Level Software AG in Saarbrücken

Everyone knows it, few use it

Playwright and end-to-end tests were no strangers to the room. Most people had heard of them, few were actually using them. What was new to many were the different approaches: tests against mocked APIs, tests against a real backend with Testcontainers or Docker Compose, traces for analysing failures in the pipeline.

That is exactly what I hear when I talk to other companies. Everyone agrees that quality is essential and that a tool like Playwright helps. And then the investment either doesn't happen or stays on the surface.

The people at the Saarbrücken meetup learned something new, asked engaged questions and left able to dig into the topic in a more targeted way.

Testing culture comes from the team

What I take away from projects: the initiatives that actually led to broad adoption always came from the bottom up, from the team itself.

That is how it went for us at a large client. We tried Playwright within our own team, built it in for the critical scenarios, and then passed our experience on to the other teams along with a recommendation. From there it spread. Today Playwright is the go-to solution there.

My worst talk in a long time

In September 2026 I was invited to speak at the .NET User Group Karlsruhe about "Playwright Beyond the Happy Path". I have to be honest: it was my worst talk in a long time. Sorry to everyone who was there.

Sven Hennessen sitting at a laptop in front of a projection screen showing the Playwright test runner with the "Deploy or Die" demo app

The demo didn't run. I had no internet on site, and the browser binaries Playwright needs for the tests were missing from my machine. I simply hadn't thought of it.

The evening was still worth it, thanks to the discussion. Playwright was well known in Karlsruhe too, and in some places it was already in use. We had a constructive conversation about when Playwright pays off and when it doesn't.

When E2E tests pay off

My advice is always the same: respect the test pyramid and use E2E tests sparingly. Even in the age of AI, they take more effort to write and maintain than unit or integration tests, and keeping them stable is real work.

A permanently failing end-to-end test makes about as much sense as Stack Overflow in 2026.

That's why E2E tests belong where a bug really hurts: the critical flows that cut through every layer. For everything else there are faster, cheaper tests. If you want to get started with Playwright, I've covered that in UI Testing with Playwright.

A second wind for Playwright

What really changed between the two talks is the role Playwright plays. In 2025 I still filed the Playwright MCP server under "experimental, but promising". In 2026, AI gave it a second wind.

Through the MCP server and the Playwright CLI, coding agents can do more than remote-control a browser. They hook straight into the E2E tests, run code inside the live browser session, test exploratively and can even record videos via the CLI. So Playwright has become the automatic all-purpose remote control for browsers, video recorder included.

I use this today for UI development in client projects and for demo videos, which I produce with the Playwright CLI and ffmpeg.

The most important point is a different one, though. An AI always needs a way to check its own work. In Andrej Karpathy's model, that's the verifier, one of the three layers: spec, verifier and environment. In UI development, that verifier is visual by nature. Without looking at what the browser actually renders, an agent can't tell whether it's done and whether everything works as intended. Playwright gives it that view.

What I take away

The interest in E2E testing is there, the execution lags behind. What worked for us was one team getting started, covering the critical scenarios and passing on what it learned.

In December I'll be talking about Playwright again at IT-Tage in Frankfurt, this time with internet.

Sources

Need support?

Want to bring E2E tests into your pipeline so they run reliably and actually help your team? We help you pick the right scenarios, integrate Playwright cleanly into CI/CD and keep your test pyramid in balance.

Explore DevOps & CI/CD