Teaching Copilot Your UI: The Playwright MCP Learning Loop for Polarion
Copilot knows your Java API — but it has no idea what your Polarion UI looks like. Playwright MCP gives it eyes. Here's the learning loop that turns failed tests into permanent rules, and how the whole thing becomes a release gate.
Copilot knows your Java API. It knows your REST endpoints, your request shapes, your error codes. What it doesn't know is what your UI actually looks like, which button triggers which panel, which iframe wraps the editor, which CSS class signals that the page has finished loading.
That gap used to mean UI tests were a manual job. You'd write selectors by hand, paste DOM snippets into chat, paste screenshots, explain the structure. It worked, but it was slow enough that most people skipped it and so the UI stayed untested, and bugs reached production.
Playwright MCP closes that gap. And the way it does it fundamentally changes how you think about testing with Copilot: it doesn't just generate code, it actively explores your application to understand it.
Table of Contents
- Why UI Tests at All?
- Why Playwright?
- The Loop: Generate → Run → Fail → Learn → Refine
- Playwright MCP: Copilot Gets Eyes on Your UI
- The Skill: Playwright Autopilot
- Two Test Types, One Suite
- Docker as the Release Gate
- What This Week Is About
Why UI Tests at All?
If you already have unit tests, you might wonder what UI tests add. The short answer: unit tests verify that your code does what you think it does. UI tests verify that your plugin actually works in a real browser, against a real Polarion instance, the way a user would use it.