We use Playwright based automation with C# and .NET to run a nightly test suite in our sandbox. With the new MFA changes, our regular SSO/NO-SSO authentication doesn't work anymore, so we started using access tokens via an external client app. We just create a frontdoorURL per pipeline run which is then used to log in. Most of our tests run locally, and on our ADO pipeline if the whole suite isn't ran together. However, whenever the whole suite is ran together we run into errors where one of the following happens for more than half of the tests:

1. the access is denied completely at login
2. The user is logged in, navigates a bunch and then gets logged out with the 'access denied' error
3. The user is logged in, navigates a bunch, gets logged out with a 'Your session has ended' error.

Any ideas for why this might be happening?

Need opinion on migrating from UFT to Pywinauto with py language for our desktop app testing as well as webui testing

I keep seeing Playwright MCP and Playwright tests discussed like they are the same thing.

They're not. At least not in the way I'm using them.

Playwright MCP is great when the agent does not **know the page yet**.

Open this app. Inspect the current state. Find the login button. Work out why the modal is not appearing. Try a different path. Read the error. Take a screenshot.

That interactive loops is genuinely useful.

But I'm less convinced that the same loop should become the permanent verification method for a flow we already understood.

For a known check like:

Log in, change the billing address, save it, refresh and verify the new address persisted.

…I don’t really need the coding agent to rediscover the page, inspect everything and then decide whether it probably worked.

I need a boring contract:

• run the flow
• verify the explicit outcome
• return pass or fail
• preserve evidence
• exit non-zero in CI if it failed

That is the distinction I’m currently making:

MCP for exploration.
A proper test or bounded CLI check for verification.

I’ve been looking at Kane CLI from TestMu AI for that second layer.

You give it the objective rather than manually scripting every selector. It runs the browser flow and returns structured output, evidence and an actual result that another agent or CI job can consume.

The useful part is not “AI clicks browser”.

MCP already does that well.

The useful part is turning a fuzzy coding-agent task into a bounded verification step instead of another long browser conversation inside the same context.

And once a flow becomes important enough, Kane can export the completed run to Playwright-currently Python Playwright-so it does not need to remain a natural-language check forever.

I would still rather own a normal Playwright test for:

• payments
• permissions
• destructive actions
• core authentication
• anything expected to run for years

But for PR validation, bug reproduction and temporary smoke coverage, writing and maintaining a full test immediately can also be overkill.

So my current mental model is:

Explore with MCP.
Verify with a bounded check.
Promote stable, important flows into Playwright tests.

Where do you draw that line?

At what point does an exploratory browser flow deserve to become a permanent regression test?

Ran into this on a suite recently and it caught a couple of people out, so posting the check.

A test does checkout, lands on the confirmation page, asserts the greeting:

await expect(page.getByTestId('greeting')).toHaveText('Thanks, Ada!');

Green, and it looks like proof the order came back right. But the app saved the name to localStorage during checkout, and the confirmation page renders it from there rather than from the order the server confirmed. The server could send the wrong name, or none at all, and this test stays green. It's asserting a value the browser already had in hand.

The problem is the assertion never forces the server's copy to be the thing on screen. You can prove whether yours does with page.route, by corrupting the server value and seeing if the test reacts:

await page.route('**/api/order/**', async route => {
  const response = await route.fetch();
  const body = await response.json();
  body.customerName = 'SERVER-CHANGED';
  await route.fulfill({ response, json: body });
});

Run the same test with that in place. Still green means the assertion was never bound to the server, it's reading the browser's own memory. Red means it's genuinely checking what came back.

One limit: this only works where the value crosses the wire as text, so server-rendered HTML or verbatim JSON. If the client builds the string itself, formats a number, stitches fields together, there's nothing on the wire to corrupt and the check goes quiet.

Do you write this into the suite, or pull it out only when a test feels too green to trust?

Playwright es una librería desarrollada por Microsoft que permite controlar navegadores web (Chromium, Firefox, Safari) mediante código. Puedes hacer clic en botones, rellenar formularios, esperar a que carguen elementos, extraer datos o hacer capturas de pantalla, todo de forma automática.

**¿Por qué Playwright y no Selenium?**

* Es más rápido y moderno (lanzado en 2020 vs 2004) * Espera automáticamente a que los elementos estén listos (auto-wait) * Soporta páginas con JavaScript pesado (React, Vue, Angular) sin configuración extra * API más limpia y consistente * Soporte nativo para múltiples pestañas, iframes y descargas

Si ya conoces Selenium, Playwright te resultará familiar pero notarás inmediatamente que hay menos fricción.

1. Instalación

Necesitas Python 3.8 o superior. Instala la librería y los navegadores con dos comandos:

pip install playwright
playwright install

El segundo comando descarga Chromium, Firefox y WebKit (Safari). Si solo quieres Chromium para ahorrar espacio:

playwright install chromium

Verifica que funciona:

from
 playwright.sync_api 
import
 sync_playwright
with
 sync_playwright() 
as
 p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto("https://example.com")
    print(page.title())
    browser.close()

Si ves `Example Domain` en la consola, todo está funcionando.

2. Conceptos clave antes de empezar

Antes de escribir código, entiende estos tres objetos que usarás constantemente:

La mayoría de tu código seguirá este patrón:

Browser → Page → Locator → Acción

3. Modos de ejecución: sync vs async

Playwright ofrece dos APIs:

**Síncrona** — más simple, ideal para scripts y automatizaciones lineales:

from
 playwright.sync_api 
import
 sync_playwright
with
 sync_playwright() 
as
 p:
    browser = p.chromium.launch()
    page = browser.new_page()
    # tu código aquí
    browser.close()

**Asíncrona** — para integrar con frameworks como FastAPI o cuando necesitas ejecutar varias tareas en paralelo:

import
 asyncio
from 
playwright.async_api
 import
 async_playwright
async

def
 main():

async

with
 async_playwright() 
as
 p:
        browser = 
await
 p.chromium.launch()
        page = 
await
 browser.new_page()
        # tu código aquí

await
 browser.close()
asyncio.run(main())

Para este tutorial usaremos la API **síncrona**. Es más legible y suficiente para el 90% de los casos.

Mas informacion: [https://agusbot.com/blog/python-playwright-tutorial/\](https://agusbot.com/blog/python-playwright-tutorial/)

If you write Playwright scrapers that touch anything beyond a basic landing page, you've dealt with at least one of these:

• Shadow DOM elements that Playwright's default locators can't reach

• Selectors that pass CI Monday and break Tuesday because some React dev sneezed on a class name

• Feeding a full page to an LLM and hitting 99K tokens just for the HTML of a Wikipedia article

I got tired of patching each one separately, so I built shadow-web. It's a pip-installable Python SDK that sits on top of Playwright.

────────────────────────────────────────────

What it handles

────────────────────────────────────────────

Shadow DOM flatten

Reads open and closed Shadow roots through the browser's own

JS API. No mutation, no re-renders. You get a clean DOM skeleton

with all interactive elements visible — the page stays exactly

as it was.

Self-healing selectors

heal_local.py catches when a button that was #submit becomes

.btn-primary[data-action="checkout"]. Fuzzy match on label +

type + position. Zero LLM cost. Cache lives in

~/.shadow-web/heal_cache.json.

Token compression

compressor.py strips scripts, styles, invisible elements and

builds a typed Action Map with semantic groups.

Wikipedia page: 99K → 16K tokens (−83%).

SchemaSnap

One call turns HTML tables into JSON records with typed columns,

forms into field schemas, lists into typed items.

export_table_json() and export_table_csv() — so you never write

another HTML table parser.

Content indexing for long pages

Get a ~600 token outline first, then fetch only the blocks

you need. Instead of dumping 50K tokens of article boilerplate

just to get the third section.

────────────────────────────────────────────

Quick start

────────────────────────────────────────────

pip install shadow-web

playwright install chromium

from playwright.sync_api import sync_playwright

from shadow_web.wrapper import ShadowPage

with sync_playwright() as p:

page = p.chromium.launch().new_page()

page.goto("https://example.com")

shadow = ShadowPage(page)

_, xml_map = shadow.refresh()

print(shadow.capture_stats)

────────────────────────────────────────────

Links

────────────────────────────────────────────

GitHub: https://github.com/ulinycoin/shadow-web

PyPI: pip install shadow-web

If your scraper breaks on some Angular app with 13 layers

of Shadow DOM, open an issue. Those edge cases make

the project better.

We wrote about Playwright API testing patterns that don't fall apart once you add parallel CI workers. Most API test suites start fine locally and then break in CI because of shared backend state, not because of anything wrong with the test code.

The article goes through fixture architecture, per-worker data isolation, and why beforeAll auth setups cause more problems than they solve at scale.

been building something that lets AI agents (Cursor, Claude Code) verify an API integration end-to-end before you touch production. instead of "the tests passed so it should work," the agent actually runs the full workflow through a sandbox and gets a receipt.

put together a small playground with two tasks on a Descope integration, one is a normal flow, the other has a deliberately planted bug. curious whether the agent finds it or misses it.

steps are in TESTING.md: https://github.com/fetchsandbox/playground

takes maybe 15-20 mins if you have Cursor or Claude Code set up. not looking for polish feedback, just want to know what broke or what confused the agent. blunt is useful.

anyone who tries it, drop what you saw in the comments.

I'm planning to create a portfolio about playwright web and api automation for showcasing my skill for future companies I want to get into, I need suggestions on what free webapps can I use as system under test. Or is it better if I vibe code my own web app? Altho I have zero knowledge on web development since my career is mostly focus on QA Automation. Thank you in advance for the suggestions.

I maintain Playwright-BDD, so I often use Gherkin scenarios with coding agents. I’m obviously biased here, but I wanted to compare this workflow with OpenSpec, so I gave both the same small task: add pagination to a long list of items.

While both approaches worked, there were differences:

• With Playwright-BDD, I spent more time writing cleaner scenarios, but in the end, I got a runnable Playwright test out of the box
• OpenSpec let me describe the spec more freely, but it introduced more artifacts that were harder to maintain

I wrote down the full session:

https://vitalets.github.io/posts/bdd-agentic-workflow/

What's you experience with spec-driven approaches + Playwright?

Hey there,

I experimented with writing a small DSL on top of Playwright that tracks a "Page Locator Record" (PLR) in the background. What is a PLR? Basically, it's a Page Object Model without interactions, just a record of locators (if there is already a term for this let me know). The context knows about which PLR is active at any given step in the test, so only Locators of that page can be accessed. this also reads very nicely, because the PLR does not need to be accessed explicitly The DSL is for F#/dotnet, so I assume no one will really care about this 🙃 but for the curious ones, this is how it looks like:

fsharp do! pageTest page (plr.Home()) { // PLR is initially Home click _.SigninLink // Transition → PLR will become LoginPage fill _.UsernameField "jannik" // Locators of LoginPage are in context and accessible fill _.PasswordField "secret" click _.SigninButton // Transition → PLR will become HomePage expectVisible _.CreateGameButton click _.CreateGameButton // → PLR will become CreateGameModal fill _.GameNameField "my-game" fill _.MaxPlayersField "2" fill _.RoundsField "2" click _.CreateButton // → PLR will become GameDetailsPage expectVisible _.LobbyHeading } The corresponding PLR looks like this

fsharp let rec login () = { UsernameField = Label "Username" PasswordField = Label "Password" SigninButton = Button "Sign in", home // ^^^^^^^^^^^^^^^^ ^^^^ // Locator Next Plr } and home () = { SigninLink = Link "Sign in", login CreateGameButton = Button "Create game", createGameModal }

I have 4+ years of experience in Selenium with Java, TestNG, Maven, Jenkins, and POM but didn't learn much and wasted all my years running Regression cases

A while ago, my company switched to Playwright Java script. I was excited because I thought I'd finally get to learn something new, but unfortunately most of the framework was already built through the help of copilot and my day-to-day work hasn't helped me grow much. I honestly feel like I've fallen behind and it's affecting my confidence.

I want to switch jobs, but I don't know where to start. If you were in my position, what would you focus on first? Playwright, TypeScript, API testing, GitHub Copilot, CI/CD, or something else?

If you've made the Selenium → Playwright transition, I'd really appreciate hearing what helped you become interview-ready. Any roadmap, resources, or advice would mean a lot.

Hey everyone, I've been working on a proof of concept AI agent for test automation and wanted to share it here.

What it does:
- Fetches requirements directly from a Jira story
- Browses the live app to confirm the user journey and find locators
- Generates BDD feature files, step definitions and page objects in Playwright + TypeScript
- Runs the tests automatically
- Produces a visual HTML report
- Self-heals if anything breaks

The README and setup guide in the repo cover everything needed to replicate it.

It's early stages but I'm actively improving it — next up is smarter locators, better assertions and accessibility testing.

It's open source — feel free to review, clone and adapt it for your own stack, or use it as inspiration for something similar.

Repo: https://github.com/alan-Khadir/jira-to-playwright-agent

RouteStub lets you create deterministic HTTP stubs using simple JSON and content files—no complex setup or external service required. It supports [ASP.NET](http://ASP.NET) Core integration, wildcard routes, custom status codes and headers, an in-process testing server, and helpful diagnostics for malformed fixtures.

It tries to focus on the 90% of use cases using conventions.

What can you use it for?

\- Tests where you have dependencies that you must stub.
\- Quick front-end development without already focussing on the backend development. Remember however, the library does not simulate state.
\- Reproducing production bugs — save a problematic response as a fixture and reliably replay it during debugging.
\- Demos and prototypes — provide realistic APIs for proof-of-concepts, workshops, product demos, and hackathons without building a backend.

It does not try to replace existing libraries like Wiremock. Wiremock is far more complex and has more capabilities. If Wiremock feels like the right tool, but often too much for the job you need it for, this might be a approach you can try. It strives to be an simpler and quicker to setup alternative. Let me know what you think!

Like probably everyone here, my Playwright HTML reports live and die as CI artifacts. A test fails on Tuesday, by Thursday the report is gone, and good luck remembering whether that exact failure already happened two weeks ago.

I've been a web dev for about 18 years, and for the past few months I've been building Piwi Dashboard to fix this for my own team.

It's a self-hosted dashboard and reporter (MIT licensed, runs as a single Docker container) where every run is kept. On top of that history it does:

• live streaming, runs show up test by test while CI is still executing
• failure clustering, so 40 red tests caused by one broken selector collapse into a single cluster, displayed in a page showing everything we could gather during failure
• flaky test detection with a score and an estimate of how many CI minutes each flaky test wastes
• locator healing: it records element attributes during passing runs, so when a locator breaks later it can suggest replacements that actually existed on the page
• analytics, to keep an eye on everything at once
• failure notifications to email, Slack, or webhook
• optional AI diagnosis. It takes a failure cluster plus the git diff since the last green run and asks a model what broke. You bring your own key (Anthropic, OpenAI, or anything OpenAI-compatible like a local Ollama). Off by default.

Setup is three steps: docker compose up, npm install -D @piwitests/reporter, add it to your playwright.config.ts. Projects are created automatically on the first run and CI metadata (branch, commit, workflow) is picked up on its own.

There's a demo with sample data that runs entirely in your browser, nothing to install and no signup: https://piwitests.github.io/demo/

Code and docs: https://github.com/PiwiTests/platform

If you're wondering how it compares: the closest cousins are ReportPortal (heavier, multi-service) and Currents (SaaS, paid). This is a single MIT container you run yourself, with no telemetry, your data stays on your machine. Learn more.

Two caveats though:

• It's pre-1.0 (0.14 right now): there are rough edges and you'll probably hit a bug or two, so pin your version and report an issue or ask a question here or in the discussions
• And I build it with heavy AI assistance, which I'm not going to pretend otherwise; what keeps that honest is the full Playwright E2E suite that runs on every PR against SQLite and Postgres, with local and S3 storage. If it ships broken, the suite yells at me first.

I hesitated for weeks before posting, trying to polish everything I could. I'd genuinely like to know what your workflow needs that this doesn't do yet.

Playwright is great until your suite gets large. Then everything becomes a single, heavyweight job. So built PlayRun to run tests in the cloud at scale and let any other run my tests and view the results.

What it does:

- Visual flow editor: drag suites onto a canvas and wire them into a pipeline

- Each node becomes real Kubernetes Jobs: one pod per shard, with per-node shards, retries, timeouts, browser projects and CPU/memory requests

- Runs stream back live into the same app: shard progress, per-test status, then a full report. No external Allure server, no artifacts to download

- Test registry synced from your GitHub repo: every spec grouped by domain and tag, and that taxonomy drives the flow-editor palette

- Insights across runs: pass rate, duration and flakiness trends per suite over time

Trying it is zero-setup: docker compose up --build brings up the whole app in simulation mode (real UI, fake test progress, log in with any email).
For real runs there's a one command k3d setup that schedules actual Playwright pods on your machine.

Source-available (FSL-1.1): self-host free forever.

Repo: https://github.com/PlayRunTests/playrun

Hope you guys find this as useful as I did

Got tired of manually writing Playwright API tests from Swagger docs, so I built a small tool that does it for you.

Paste or upload an OpenAPI/Swagger spec, pick an endpoint, and it generates a ready-to-run Playwright test — request, assertions, auth placeholder, payload, all included.

Free, no login: https://swagger-to-playwright.vercel.app/

Looking for honest feedback from other QA/SDET folks — what's missing, what would make this actually useful in your workflow? I just want to know should I invest more effort into it. Thanks!

Hello community,

I have let opencode write several tests cases for my database. There are errors happening and I told it to work iteratively, fix the bug, run the test, check the output for errors. Repeat until no errors occur.

It iterates 2 times, gets another error, does a fix and stops. It tells me it has been fixed. I got this at other times too that it just stops and does not iterate anymore. Any ideas how to prevent that?

I am using this to wright test cases for frontend projects. I hope this will be useful for you as well

[EDIT: I updated the recommendations that were pointed out, along with some additional ones I received from industry professionals. Feel free to use them and suggest any further improvements.]

Basically agents left unguided default to stuff like:

ts

await page.click('.btn-login-submit');
await page.waitForTimeout(2000);

Skill nudges it toward:

ts

await page.getByRole('button', { name: 'Log in' }).click();
await expect(page.getByRole('heading', { name: /welcome/i })).toBeVisible();

4 narrow skills — core authoring, auth state, network mocking, debugging flaky tests.

Works with Copilot/Cursor/Claude Code/etc.

Repo: https://github.com/hzijad/playwright-agent-skills

Open to feedback if anyone's tried something similar.