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

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.

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!

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?

[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.

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

Hi all, we don't intend to spam or anything, but our team recently shipped this Endorm-Vercel integration. We have been through this situation so many times: tests pass on localhost and then break in the real build, because cache headers and JS bundling behave differently once it's deployed. This runs your Playwright suite against the Vercel preview instead and handles the deploy-ready wait and protection bypass, so you don't have to script them yourself.

Do give it a read and try it out. I will be really happy to answer any of your queries.

I am attempting to implement snapshot assertions within Playwright Python and have discovered that this functionality is not natively supported.

Could you please recommend suitable alternatives for visual assertion?

I have identified several repositories on GitHub; however, their reliability appears questionable.

Is visual regression testing still considered a necessary practice in 2026?

I am seeking clarification and insights from the Python community on this matter.

What do test automation tools share and where do they split architecturally?:

What they share:

All claim to reduce manual test maintenance

All have some form of AI assistance in the workflow

All offer CI/CD integration

Where they split:

Applitools: screenshot comparison layered onto Appium or Espresso, framework dependent

Testim Mobile AI: AI locator finding, still selector dependent execution underneath

The execution model that breaks from this pattern entirely is the one Autosana takes, verifying React Native flows visually without any element tree dependency

Our team wrote this article after benchmarking the default workflow npm init playwright@latest generates. 40 tests took 3m18s, and 42s of that was just re-downloading the browsers on every push, while the tests ran on a single worker because the scaffold hardcodes workers: 1 in CI.

It also walks through caching the binaries, fixing the worker count, and explaining why sharding is usually the wrong first move.

A new version is out, and the main addition is PW-Core Codegen.

To start recording:

bash npx pw-core codegen

I like Playwright's Codegen, but I always found myself spending more time cleaning up the generated code than recording the test itself.

So I built a recorder that works a little differently.

Instead of only generating a script, it can:

• Reuse existing locator registry entries
• Update the registry instead of creating duplicate locators
• Automatically create missing page objects
• Treat every unique URL as a separate page and generate the corresponding page object
• Generate ready-to-run Playwright tests
• Continue recording multiple tests (serial & parallel) in a single session

The idea is simple.

Recording a test should extend your framework instead of creating work afterward.

Codegen Documentation

https://qecore.github.io/pw-core/docs#pw-core-codegen

Release Notes

https://qecore.github.io/pw-core/docs#releases

I'd genuinely appreciate feedback, especially from people maintaining medium or large Playwright projects. What part of your current recording workflow annoys you the most?

Note: The documentation is best viewed in landscape mode on mobile devices.

Hi there testers,

I work as QA for 7 years already, and a lot of the time is not spent testing.
It is spent rebuilding context.

Read the Jira ticket, documentation on Confluence, find the repository.
Work out how the existing tests are structured, check the PR, wait for CI results.
Then explain the result back in Slack.

I’m building Framebox around that problem.

The idea is simple: keep the QA workflow in one Slack thread, while connecting the actual sources of truth behind it: Jira, GitHub and CI.

In this short demo, I give the agent a Jira ticket about mobile checkout coverage. It uses the ticket context, checks the existing Playwright setup, creates a GitHub PR, explains the changes, and reports the mobile CI outcome back in the same thread.

The agent is not meant to decide whether quality is acceptable.
That still needs people who understand the product, risk and users.
The goal is to reduce the boring context reconstruction and leave an evidence trail:
> ticket → implementation → PR → CI result → results on Slack thread.

Technically, the Slack thread is the unit of work.
It keeps the relevant repo, PR, intent and CI context available between messages.
Workspace knowledge can also add testing conventions, project documentation and runbooks, so the agent is not starting from zero every time.

I’m still early in the build, so I would genuinely value the blunt version of feedback:
- Would you allow something like this to create or update tests and PRs?
- What evidence would you need before trusting its output?
- Is context switching between Jira, GitHub, CI and Slack actually a problem in your team, or am I building a very expensive browser tab?