r/Playwright

I've been working on my first ever full length play for about a year now. Last week I got the chance to do a table read with actors and it ended up taking us about 3 hrs and 20 minutes to get through it. If performed as is, this play will likely be close to 4 hours which I know is unreasonable. The actors really loved the story and everyone thought the script was really fantastic so I'm torn. I know there's some fat I can trim but I don't think I'll ever be able to get this story down to a 2 hour play. Am I screwed? What should I do?

I recently joined a new repo and noticed the codebase has two different styles of Page Object Model patterns and I was wondering if there's a preference. From the docs I only see references to the class-based pattern.

Class-based:

  class AddTodoPage {
    public readonly page: Page;
    public readonly titleInput: Locator;
    public readonly submitButton: Locator;

    constructor(page: Page) {
      this.page = page;
      this.titleInput = page.getByRole('textbox', { name:
   'Title' });
      this.submitButton = page.getByRole('button', {
  name: 'Add Todo' });
    }

    async goto() {
      await this.page.goto('/todos/new');
    }

    async fillTitle(title: string) {
      await this.titleInput.fill(title);
    }

    async submit() {
      await this.submitButton.click();
    }
  }

  // Usage
  test('Adds a todo', async ({ page }) => {
    const addTodoPage = new AddTodoPage(page);
    await addTodoPage.goto();
    await addTodoPage.fillTitle('Buy milk');
    await addTodoPage.submit();
  });

Factory function:

  function createAddTodoPage(page: Page) {
    return {
      goto: () => page.goto('/todos/new'),
      fillTitle: (title: string) =>
  page.getByRole('textbox', { name: 'Title'
  }).fill(title),
      submit: () => page.getByRole('button', { name: 'Add
   Todo' }).click(),
    };
  }

  // Usage
  test('Adds a todo', async ({ page }) => {
    const addTodoPage = createAddTodoPage(page);
    await addTodoPage.goto();
    await addTodoPage.fillTitle('Buy milk');
    await addTodoPage.submit();
  });

How do you guys handle virtual scrolling in a data grid.

Eg: If a page has 200rows of data and DON only loads first 70rows. I have added a row which can be a row 101 or row 199. How do you verify that the row got added.

Built Sentinel after burning through LLM credit testing browser-use and Stagehand on a client project. Both feed large chunks of the rendered DOM back to the LLM every step - token costs spiral on multi-step flows.

The trick: feed the LLM Chrome's accessibility tree (what screen readers use) instead of the DOM. It's 10-50x smaller and every element comes pre-labeled (button, textbox, etc), so the LLM stops guessing what's interactive.

9-task benchmark, same model (Gemini 3 Flash), 5 runs each:

• 3-57x fewer tokens than browser-use
• 1.4-13x fewer than Stagehand
• 0/45 failures vs 0/45 (browser-use) vs 6/45 (Stagehand)

In production with paying clients (all self-hosted). MIT, TypeScript. Self-host is the default path. If there's demand for managed hosting I'll add it at cost - infra + model usage, no margin on top.

I built it, so verify the benchmark yourself - raw JSON per run is committed.

• Source: https://github.com/ArasHuseyin/sentinel.ai
• Benchmark: https://github.com/ArasHuseyin/browser-agent-benchmark
• Web: https://www.isoldex.ai

Curious where you'd expect this to break down - heavy canvas/WebGL UIs is my own guess.

Hi Friends, our company started saying to use Playwright-CLI with Claude code, I am new to this, couldn’t find online videos for end to end scenarios for automation scripts. Can anyone please share some ideas, how can I use to create automation scripts and POM files? Thanks in advance 🙏🏻

I was just at an interview in England, and they gave me a task to do coding for the interview.

I was surprised how much i forgot from the synthax since for years I have been using Github Copilot.

Things are more like a complex structure to me rather then code.

- POM

- Fixtures

- ENV files

- Config

- Authentication

I don't think in ...writing code per se. I am more of an orchestrator.

So why question my coding abilities?

My app authenticates via an external OAuth 2.0 provider. I added a worker fixture that runs before each test and saves the storage state for a unique user into a file - this works fine.

But I’m going to have some tests where this isn’t necessary: a single user would be enough, since the state won’t change.

What’s the best way to handle this?

1. Create a new fixture that saves the storage state for one shared user
2. Do it via a setup project with project dependencies?

As I see it, both approaches have a downside: test organization. I’d have to move the tests that don’t modify state into a separate folder. But the spec/test cases that automation is based on doesn’t account for that, so it could easily lead to chaos and confusion.

Any advice would be appreciated.

Hey Reddit,
I’ve spent the last 5+ years fighting flaky E2E tests and false-positive pipeline failures.

Recently, I started experimenting with autonomous coding agents to write test scripts. They can generate hundreds of lines of code in seconds, but I quickly noticed a massive flaw: they greedily write brittle, static tests just to make the pipeline pass in the moment. The second a developer changes a CSS class or a UI rendering is delayed, the test breaks, and someone has to manually intervene.

I realized that simple "self-healing" or prompt-engineering an LLM to guess a new selector isn't an actual fix—it's just a band-aid.

So, I decided to take a completely different architectural approach. I open-sourced a framework called agent-qa, but instead of making it a standard test generator, I built it around the concept of an "evolving execution memory."

Here is how the architecture is set up:

1. It uses Playwright (web) and Appium (mobile) strictly as a low-level execution kernel.
2. The AI harness sits on top, but it doesn't write static code. It executes steps written in natural language by observing the actual screen state and accessibility tree.
3. The core difference: With every test run, it builds persistent Product, Suite, and Test memory. If it encounters a broken UI element, it attempts alternative paths to heal the test on the fly. Crucially, it saves that successful intervention to its memory so it doesn't waste tokens or time making the same mistake on the next run.

It basically learns your application's navigation model over time, dropping execution time and token usage significantly on subsequent runs.

I’m looking for brutal feedback on this architecture from other QA and automation engineers.

Link to the open-source repo and the technical docs is in the comments. Let me know what you think of the execution memory approach.

Two tools can both accept natural language input and work completely differently the moment a refactor happens. Here is what is actually going on under the hood: LambdaTest Kane AI: Model generates the test script, a locator driven runner executes it Rename a component, restructure a screen, the test breaks the same way it always did Eggplant: Scripted execution with AI layered on top, enterprise pricing, significant onboarding required Has been doing screen level execution for years, accessibility is the problem not the concept Autosana: Autosana reads what is rendered on screen rather than what is declared in the codebase Code changes that leave the visible interface unchanged don't register as failures Covers iOS, Android, and web from one setup without locator configuration LambdaTest and Eggplant both couple the test to the app's code structure in different ways. Autosana couples it to the screen instead.

I created an open source playwright report that groups failures by root cause and outputs shareable link to slack or CI.

You can generate a url on our domain or use your own server to set it up. Secrets are masked so user data won't be leaked. It's a two step process that doesn't require you to change or adapt your tests.

Here's the repo and sample report:

• Sample report
• Github Repo

I would love if I someone would try it out and give me feedback on what to add, what to improve and if you find this useful. In my experience a lot of companies either don't have this, or they take the time to build it internally.

Processing img 09u0pymeqx1h1...

​Hi everyone,

​I’m looking for some advice on automating a tedious weekly task at my company, and I want to see if anyone here has successfully tackled a similar problem using modern AI tools.

​The Situation:

Every week, our team has to manually click through a dozen or so test scenarios on our application across various client environments. It’s basically repetitive smoke testing that takes up too much time.

​What I want to achieve:

​Write the test scenarios in plain natural language as a simple list of steps (e.g., "Log in, go to settings, change the username, verify the success message").

​Feed these steps into an AI Agent that can interact with the browser, analyze the page in real-time, and execute the steps.

​Crucial requirement: The tool must not just generate Playwright/Selenium code. I need an agent that actively navigates the page and can adapt on the fly if the layout or CSS selectors change slightly, as long as the underlying logic remains the same.

​Privacy is a must: Because we deal with sensitive client data, I need to power this agent using a local, self-hosted LLM (running via Ollama, vLLM, etc.) so no data leaves our infrastructure.

​I’ve heard of frameworks like Browser-Use, LaVague, or Skyvern, but I’m not sure how well they handle local open-source models (like Llama 3 or Mistral) for reliable E2E testing, or if there are better enterprise-ready/open-source alternatives out there.

​Has anyone built a similar pipeline? What tools, frameworks, or specific local models worked best for you to achieve high reliability without constant maintenance?

​Thanks in advance for your help!

Test suite runs in around 5 mins locally with 4 workers. With 2 workers in pipeline the execution time goes to more than 20 mins and sometimes for an hour, and sometimes a lot of the scripts fail.

Also, what logic do you guys use for pipeline execution, I have set up smoke test when deploying code, but it should be after post deployment right? And the cron job which runs everyday runs the whole test suite. I am new to this so not clear how to approach this, it's a simple company website, checking if all pages load, navigation works, careers page and contact form works. My company expects me to automate every project in our company, I shouldn't be struggling with a simple company website this much. Any suggestions are appreciated. Thank you

Is there any chance that we'll get support for Ubuntu 26.04 anytime soon or is there a way to install it with --with-deps and some tweaks, that it actually works?

After months of brittle tests, I ran a deliberate comparison of selector strategies on a React app with frequent DOM changes.

Approach 1: CSS selectors - Fast to write, first to break. Any class refactor killed half our suite overnight.

Approach 2: data-testid attributes - Solid until you're testing third-party components you can't annotate. Also requires dev buy-in, which isn't always realistic.

Approach 3: ARIA roles + getByRole - This became our default. It survives styling changes, encourages accessible markup, and fails loudly when the UI actually breaks in a meaningful way rather than just a rename.

The tradeoff nobody mentions: getByRole requires your team to understand ARIA, which has a real learning curve. We had to do a short internal workshop before it clicked.

One thing that forced us to get even more disciplined about selectors: we also use Playwright for scrapin͏g workflows (collecting competit͏or pricin͏g data behind residential rotat͏ing prox͏ies via Geo͏node). When you're scraping sites you don't control, you can't add data-testid - so getByRole and robust locator chaining become essential, not optional. It changed how we thought about selector durability across our entire codebase.

Curious whether others have landed somewhere different. Anyone using locator chaining heavily, or leaning on filter() to narrow things down? I feel like that's underused in most codebases I've seen.

I got tired of anti-bot systems constantly breaking my Playwright AI agent, so I built Invisible_Playwright: an open-source, MIT-licensed Playwright and Firefox fork patched at the C++ level.

Instead of reusing the same noisy automation fingerprint, Invisible_Playwright generates a different but internally consistent browser fingerprint for each session. The goal is to remove the Playwright automation signals while keeping the browser environment coherent and reproducible.

Category	Invisible_Playwright result
Fingerprint generation	✅ Different, coherent per-session fingerprint
WebRTC	✅ Pass — no public IP leak
PixelScan	✅ Pass — no inconsistencies
CreepJS	✅ Pass — 0 lies
SannySoft	✅ Pass — all green
BrowserLeaks WebRTC	✅ Pass — no public IP leak
reCAPTCHA v3	✅ Pass — 0.90
Fingerprint Pro	✅ Pass — bot=false, tampering=false
Cloudflare / Turnstile	✅ Pass
hCaptcha	✅ Pass
DataDome-style checks	✅ Pass
Kasada-style checks	✅ Pass
Akamai-style checks	✅ Pass
Imperva-style checks	✅ Pass
HUMAN / PerimeterX-style checks	✅ Pass
Arkose-style checks	✅ Pass

Repo: https://github.com/feder-cr/invisible_playwright

TLDR: We wrote a decision framework for splitting Playwright tests between staging and production, including when production testing isn't worth the operational cost.

Either you trust staging or you don't.

The real problem is that staging and production have different risk profiles, and almost nobody configures their test suite to reflect that.

The article covers what your timeouts, feature flags, parallelism, retry policy, trace capture, and auth setup should actually look like in each environment, and when production testing creates more problems than it solves.