Why E2E tests lag behind
In a workflow-heavy app like Property Plan, the risky bugs are rarely inside a single component. They sit in the path through several screens: a report that cannot move to the next status, a form that loses its state on mobile. That is what end-to-end tests are for, and it is also what they are slowest to write for.
Writing a good E2E test means clicking through the app, finding stable selectors, waiting for the right thing, and doing it again when the UI changes. That friction is why E2E coverage usually trails behind the features.
What MCP adds
The Model Context Protocol lets an AI assistant use tools. The Playwright MCP server is one of those tools: it gives the assistant a real browser it can open, click through and read, using the accessibility tree instead of screenshots.
That changes the loop. Instead of me clicking through a workflow and translating it into code, I describe the scenario, the assistant walks through the app, and I review and shape the test it proposes.
How I used it
Describe the scenario
In plain language, from the user’s side: register a damage report, assign it, close it.
Let it explore
The assistant opens the app, finds the elements by role and label, and reports what it sees, including where the flow does not do what I described.
Review like any other code
The generated test goes through the same review as hand-written code: role-based selectors, no fixed timeouts, one clear assertion per step.
Run it in the pipeline
The test runs in CI with plain Playwright. MCP is only used while writing, not while testing.
What I watch out for
An assistant happily writes a test that passes. That is not the same as a test that fails when it should. I still break the feature on purpose once to see the test go red.
Accessible markup pays off twice. The same roles and labels that help screen reader users make the app easy to navigate for the assistant, and make the tests stable.