Using Playwright - End-to-End testing for Modern Web Apps

21 May, 2025

Using Playwright

When I first got asked to write Playwright tests, I wasn't that excited (TBH) :D

I hadn't written end-to-end tests before. And the whole idea felt a bit... heavy.

"Write tests that simulate user actions from start to finish"

Sounds simple, but in reality, I had no clue where to start. The framework was already set. The test runner was in place. The structure existed.

But still, it felt overwhelming at first.

So I started slow - opening a test file, reading through how things were written, running them locally, breaking them by accident.

Eventually, I understood what was going on.

At the time, I was working on building workflow configurations for connectors. Overview profiles, tabs, and states — a lot of moving parts.

I started with simple checks:

• Does the page open?
• Are the tabs showing up based on the type?
• Does this connector show the compaction and caching fields?
• Are filters and blocks rendered correctly?

Bit by bit, I wrote tests that made sure features didn't quietly disappear with new changes.

And somewhere along the way, it stopped being "just a task" and started making sense.

Later, while working on an initiative, I had to test more complex flows, like multiple navigation, dynamic data loading, adding data-test-ids, identifying locators, and emulating dropdown events. These weren't light tests.

That's when I came across something new: Playwright MCP by Microsoft.

It looked interesting, and this was the perfect use case to try it out.

What is Playwright MCP?

Playwright MCP is a Model Context Protocol server that lets tools like LLMs interact with web pages, not through screenshots or pixel detection, but using the accessibility tree from Playwright.

It has two modes:

• Snapshot Mode (default): Uses structured data from the accessibility snapshot
• Vision Mode: Uses screenshots and X/Y coordinates

For my testing, I used Snapshot Mode. Mainly because:

• It's fast
• It gives a clean structure to the page
• It doesn’t rely on pixels or visuals — just accessible HTML structure

How I used it

The goal was simple: fix the broken Playwright test for the connector in the configuration

Here's how I approached it:

1. Opened the project in Cursor Editor

2. Locate the relevant test files and folders for the failing scenario

3. Used existing Playwright reports to get a sense of where it was failing

4. Launched Playwright MCP in Snapshot Mode

5. Used the following commands:

   • browser_navigate: to load the page
   • browser_click: to interact with the broken element
   • browser_snapshot: to view the structured accessibility data

This helped me inspect the current page structure, spot mismatched or missing locators, and fix the test directly without guessing.

Looking back, I'm glad I started with those first few tests, even though it felt like a lot.

Writing tests helped me understand the system better. It also made me more confident about the code I shipped.

Now I don't wait for something to break in staging. I add a test and move on.

If you're in the same place I was — unsure about testing, unsure where to start — just begin with one.
Read a test, run it, break it, and fix it.

You'll figure it out.