r/Playwright

reCAPTCHA v3 at 0.3, FP Pro flagging bot:true, Cloudflare banning my ASN on sight. Sick of it.

Built this: a Firefox patched at the C++:

reCAPTCHA v3 0.90, FP Pro bot=false, tampering=false · CreepJS 0 lies · sannysoft all green · WebRTC no leak.

Self-hosted, MIT, no cloud, no subscription.

Repo: https://github.com/P0st3rw-max/stealthfox

Been experimenting with an open-source tool built around Playwright that resolves elements from plain English instructions like:

await t.act("Click login button")

The idea itself isn’t new — tools like Zerostep, Midscene, etc. already exist — but in our experience many of them felt slow/sluggish for regular automation workflows.

Main goal here was reducing locator maintenance and speeding up automation setup while keeping execution lightweight.

It also caches resolved selectors, so repeated runs don’t keep hitting the LLM.

GitHub: QorTest GitHub

If anyone is interested, would genuinely appreciate trying it out and sharing honest feedback/issues/limitations.

I run a few small scrapers on cron price trackers, a job feed, a stock watcher. Every couple of weeks one dies because a site renamed a CSS class. Patch, push, repeat. Maybe 30 min/month of pure boredom. So I spent a weekend on a fix.

Selfmend is a Playwright scraper where you describe each field in plain English (e.g. "the price in pounds, e.g. £51.77"). When a selector returns nothing, or returns something that fails the field validator, it sends the page's accessibility tree (not raw HTML) to an LLM, which proposes a new locator. A validator gate (type / regex / range) checks the result before it goes in the cache. So the LLM proposes; deterministic code accepts or rejects. That gate is the whole trick without it, the LLM silently corrupts your data over time.

You can checkout the project here: https://github.com/Per0x1de-1337/selfmend

I've noticed that the Playwright team closes quite a few highly upvoted feature requests/issues as not planned.

I completely understand that maintaining a project of this size requires strong prioritization, and that upvotes alone can’t drive the roadmap. Also not every feature request is a good fit for the project.

Still, I sometimes find it frustrating to see issues with a lot of community interest get closed rather quickly. Especially when those issues represent real pain points for advanced or large-scale use cases.

I’m curious how others in the community feel about this.

Hey guys,

A while ago I posted here about the gap between what an e2e test says it protects and what it actually checks.

That discussion raised a few good questions, especially around whether I was just arguing for page objects or trying to force everything into application-level tests.

I spent some time thinking deeper about the problem, and now I think the thing I've been trying to name more precisely is this:

A test can be perfectly clean and still change for the wrong reasons if it is anchored to a different scope than the promise it claims to protect.

Example:

test('create business party', async ({ page }) => {
  const partyList = page.getByTestId('Components.PartyList');

  await partyList.getByRole('button', { name: /add party/i }).click();

  const modal = page.getByTestId('Components.PartyModal');
  await modal.getByRole('button', { name: /business/i }).click();

  const entityName = modal.getByTestId('Components.PartyModal.PartyModalBusinessForm.entityName');
  await entityName.getByRole('combobox').fill('Acme Inc.');
  await entityName.getByRole('option', { name: /create/i }).click();

  await modal.getByTestId('Components.PartyModal.submitButton').click();

  await expect(partyList.getByTestId('Components.PartyList.PartyRow').filter({ hasText: 'Acme Inc.' })).toBeVisible();
});

Nothing is wrong with this by itself.

But if the promise is just:

>a business party can be created

then this test is anchored to a much more UI-specific scope:
- there is a party list with an add-party entry point
- the flow starts there
- it happens through a modal
- that modal has a business tab
- etc...

That may be exactly what you want to protect. But then it is a UI-scope contract.
Same promise space, different scope:

test('create business party', async ({ parties }) => {
  await parties
    .addBusiness({ companyName: 'Acme Inc.' })
    .create();
  await expect.poll(async () => parties.get('Acme Inc.')).not.toBeUndefined();
});

UI-scope tests are completely valid when the thing you want to protect is UI behavior. Application-scope tests are valid when the thing you want to protect is the capability itself.

The problem starts when the test sounds like it protects one scope, but is actually tied to another.
And if a test is truly UI-scope, it is worth asking whether e2e is the right place for it, or whether a smaller UI/component test would give faster, more focused feedback.

Imo that is where a lot of brittleness comes from. And it's not just naming alignment. Once those two are aligned, the whole suite - and maybe your whole testing strategy - gets much easier to reason about:
- UI-scope tests change when UI behavior changes
- application-scope tests change when the application capability changes
- mechanics can still break, but the fix is easier to locate
- "should this really be an e2e test?" is easier to answer
- it becomes easier to see when a lower-level test is creating more churn than the promise is worth

If interested, I wrote the longer version with a fuller example and more on scope alignment in the linked post.

Glad to jump back in the trenches arguing about testing practices :D

The video is the full run. The command was literally this:

qagent "Goal: I successfully buy a backpack. Steps: 1. login (standard_user / secret_sauce) 2. add 'Sauce Labs Backpack' to cart 3. open the cart 4. checkout — fill First Name, Last Name, Zip 5. click Continue, then Finish. End: I see the 'Thank you for your order!' confirmation page" --url https://www.saucedemo.com/

That's the whole spec. No selectors, no fixtures, no await page.click(...). A real Playwright browser, end-to-end, with PASS/FAIL + evidence at the end.

What's working

• google/gemma-4-26b-a4b-it via OpenRouter passes a real Gravity Forms submission (5 required fields, checkbox arrays, paired email confirmation) for ~$0.008/run, 5/5.
• gpt-4.1-mini also passes 5/5, ~6× the cost.
• --reporter=ndjson streams one JSON event per turn and a stable done envelope at the end (outcome, evidence, totalCost, finalUrl). Exit codes 0/1/2/3. So a Claude Code parent agent can shell out, parse tail -1, and act on a real verdict.

Install

npm install -g @qagent/cli
npx playwright install chromium
qagent config set apiKey sk-or-...
qagent config set provider openrouter #Or any other provider you like
qagent config set model google/gemma-4-26b-a4b-it

Claude code usage: Just tell it to test with qagent / read the readme.

Why did I build this? Because letting claude code test it's own creation fails SO MANY TIMES. And also takes ages, while burning tokens. I prefer to pay the API price (for gemma-4 that's less than a cent).

Hey folks, back with another article - this time about how to design tests that survive when the UI is refactored.

TLDR: Learn why UI refactors keep breaking Playwright tests even when the features work fine.

It covers the coupling patterns that make suites fragile and ranks selectors by what actually survives design system changes. There's also content on structuring page objects so migrations don't cascade into dozens of test failures.

Hi, I'm a Manual QA looking to learn Automation testing using Playwright with Python. I choose Python as my current employer uses Python with Playwright.

Code - https://github.com/Strawboy97/EventHub

Wrote the code myself but I used AI to generate a Readme, still have tests to add but wanted to see if I'm on the right track.

Thanks

If you’ve used Playwright MCP for more than just demo logins from YouTube, you’ve probably run into this issue: the agent misses some elements on the page, gets confused, or completely loses context.

The reason - Playwright MCP sends an ARIA snapshot to the LLM, not the full list of interactable elements from the DOM.

Together with my team, we built an MCP upgrade that:

• serializes the full DOM tree
• returns all interactable elements
• provides a complete page context

As a result, the agent gets a full picture of the page, understands how to interact with elements, and can generate significantly more accurate and comprehensive test scenarios from the first attempt.

https://github.com/MobiDev-Org/treegress-browser-mcp (open source)

Hope you find it helpful. I’d really appreciate your feedback