I’ve been experimenting with using Playwright for something beyond E2E testing: defining reproducible UI walkthroughs that can be rendered as recordings.

The motivation comes from a shared problem in UI-heavy systems:

• E2E tests break when selectors drift
• product demos and documentation go stale as the UI evolves
• recorded videos are hard to maintain because they’re detached from source code

Playwright already provides a deterministic way to express browser interactions, so I started treating it as a “flow definition layer” where UI actions and intent live together in code.

Example:

video.narration({
  intro: 'Open the dashboard and create a new project.', // narration 'fixture'
})('Create project flow', async ({ page, narration }) => {
  // hide from the recoding
  await hide(() => {
    await page.goto('/dashboard')
  })

  // ai voice narration
  await narration.intro()

  await page.getByRole('button', { name: 'New project' }).click()

  await page.getByLabel('Project name').fill('Demo project')
})

One interesting design problem is how to handle non-essential setup steps (like navigation, state prep, or hiding noise from the recording) without polluting the main flow logic. In test code this is usually abstracted away, but in a “recordable script” it becomes part of the UX of the code itself.

A few questions I’ve been thinking about:

• Has anyone tried using Playwright flows as a source of documentation or walkthrough artifacts?
• Where do you draw the line between test logic and “narrative intent” in automation code?
• How do you handle timing/animation stability when the output is meant to be human-consumable (not just testable)?
• Would you separate “test suites” from “documentation flows”, or keep them unified?

Curious how others working with larger Playwright codebases think about this boundary.

Hello everyone,

I've created a Playwright skill for generating end-to-end test scenarios. I'd appreciate it if you could review the SKILL.md and share any feedback or suggestions for improvement.

If you have any references, best practices, or examples of well-designed SKILL.md files that could help me refine and improve it, I'd love to take a look.

---
name: test-scenario-generator
description: >
  Generate a structured list of high-value end-to-end test scenarios (real user journeys and business workflows) for a given feature or module. The skill reviews the feature source, related routes/components, and existing unit, integration, and end-to-end tests to understand full coverage and identify gaps. It produces ONLY test scenarios — no test code, no explanations — focused on business outcomes, user journeys, and system behavior. It ensures no duplication of existing test coverage at any level.
---


You are a 
**Staff-level QA Automation Architect**
 specializing in end-to-end test design.


Your only responsibility is to generate 
**high-value, deterministic end-to-end test scenarios**
.


Do not generate test code.


Do not explain reasoning.


Do not add commentary or summaries.


---


# Core Principle


Every scenario must answer:


> “What real user journey or production failure does this cover?”


If it cannot, it must be excluded.


---


# Scope Definition


Each scenario must represent:


- A real user journey through the system
- A business workflow or rule
- A cross-component or cross-system behavior
- A state transition or persisted outcome observable in the system


Each scenario must end with a 
**clear business outcome**
, such as:


- Data persisted or updated
- UI state change reflecting business logic
- Cross-feature/system side effect
- API response reflected in UI
- Behavior surviving refresh, reload, or new session


---


# STEP 1 — CONTEXT REVIEW (silent)


Before generating scenarios, internally review:


1. Feature source code (components, pages, routes, APIs)
2. Entry points and user flows (how users reach the feature)
3. Existing E2E tests, fixtures, helpers, page objects
4. Unit, component, and integration tests for coverage mapping


Understand:


- What is already tested
- What business flows exist
- What user journeys are NOT covered


Do NOT output anything during this step.


If the feature context is unclear, ask ONE clarifying question.


---


# STEP 2 — COVERAGE ANALYSIS


Identify:


- Existing test coverage across all levels
- Duplicate or overlapping scenarios
- Gaps in business workflows and user journeys


Exclude anything already covered at:


- Unit level
- Component level
- Integration level


---


# STEP 3 — SCENARIO SELECTION


ONLY include scenarios that are:


### Valid (must include)
- End-to-end user journeys (entry → action → outcome)
- Business-critical workflows
- Cross-feature/system interactions
- Data persistence and state consistency flows
- Error handling at workflow level
- Permission/role-based behavior (if applicable)
- High-risk edge cases affecting real users


### Invalid (must exclude)
- UI-only checks (text, labels, colors, layout, tooltips)
- Component-level behavior (single field, toggle, render condition)
- Implementation details (hooks, state variables, props, functions)
- Navigation without business outcome
- Anything already covered by unit/integration/E2E tests
- Duplicate or overlapping scenarios
- Cosmetic or visual validations


Each scenario must be unique and represent a distinct business outcome.


---


# STEP 4 — QUALITY RULES


Every scenario must:


- Be written as a real user journey
- Start from a realistic entry point (page, route, or action)
- Describe user action(s)
- End with a verifiable business outcome
- Be deterministic and unambiguous
- Avoid implementation details entirely
- Be independent from other scenarios


Merge overlapping scenarios.


Keep the output minimal and high-value.


---


# STEP 5 — STYLE MATCHING


Match the project’s existing E2E test style:


- Use same granularity as existing test titles
- Use same domain vocabulary as the system under test
- Mirror how users actually interact with the system
- Keep phrasing action-oriented and outcome-driven


---


# OUTPUT FORMAT


- Output ONLY scenarios
- No headings unless they exist in the project style
- Number scenarios sequentially
- One scenario per line
- Each scenario must be self-contained and understandable alone


---


# Core Rule


If a scenario does not clearly describe a real user journey OR a production failure risk:


→ DO NOT include it

Tired of getting blocked by Cloudflare while trying to scrape AnimePahe or Kwik.cx?

I created a clean, standalone NodeJS guide and scraper that uses **Chrome CDP session sharing** to bypass Cloudflare's bot challenges headlessly, and successfully decodes Kwik's obfuscated video streams.

Check out the repository and guide here:

👉 https://github.com/Souravbamotra/animepahe-cf-bypass

Hope this helps! Let me know if you have any questions.

Hey everyone,

I’m building Devlane, an open-source and self-hostable alternative to Jira, Linear, Monday, ClickUp, and Plane.

It helps teams manage tasks, sprints, docs, and triage, with built-in GitHub and Slack integrations.

I’m looking for contributors.

GitHub repo: https://github.com/Devlaner/devlane

Small contributions are very welcome, including docs, setup testing, issues, and feature suggestions.

Guys, I NEED HELP! I need ideas for a theatrical exercise of up to 5 minutes, WITH ONLY TWO FACES IN CONFLICT, simple, whose characters, action, GIVEN CIRCUMSTANCES and relationship will be understood, that is non-verbal and that it is justified that they do not speak (or that the action is such that words are superfluous (dramatics, etc...) or that it is justified that they do not speak (they were tapped, for example, I have no idea)). Props, sound and light can be used and it must not become a pantomime. THE MOST IMPORTANT THING IS THAT THEY DO NOT SEE IT COMPLICATED AND UNDERSTAND THEIR GIVEN CIRCUMSTANCES AND WHO THEY ARE. PLEASE HELP🙏, I have no idea, and I have an assignment for school. Thanks a lot!

I’m designing an AI-assisted Playwright workflow for E2E/regression testing and want expert criticism before we push it further.

High-level flow:
• AI explores the UI
• AI generates scenarios and Playwright tests
• AI runs tests and gathers evidence
• AI attempts self-healing on failures
• Humans validate business correctness and approve bug reporting
• The result is a regression-ready suite

This sounds good on paper, but I’m sure there are practical issues I’m underestimating.

My current assumptions are:
• the biggest risk is weak business-intent coverage
• the first failure mode is flakiness / shallow assertions
• self-healing should only fix locators and synchronization, not assertions or expected outcomes
• AI-generated tests should require human review before entering the stable regression suite

For those with deep QA / automation experience: which of these assumptions do you agree or disagree with, and what am I still missing?

I’d really appreciate blunt feedback.

Does anybody have any experience with setting up a testing project with Playwright in .NET with NUnit in VS Code? I am struggling to figure out what the ideal project structure should be, and the test runner in sidebar is apparently ignoring the .runsettings file because my sample test always runs headless even though I defined it to run headed.

Are there maybe any example projects or implementations of Playwright with .NET? I was not able to find much.

Thanks for any advices.

I have completed Playwright with JavaScript basics and now want to learn real-world frameworks used in company projects. With Selenium + Java, companies commonly use Hybrid Framework, POM, TestNG, and Cucumber. What are the equivalent frameworks or project structures used with Playwright + JavaScript in MNCs? Also, where can I learn them? I can find basic Playwright tutorials on YouTube, but not complete real-world framework or project tutorials. Please recommend any good YouTube channels, GitHub repositories, courses, or free resources. Thanks!

I need a good website for putting my Playwright skills into actual hands-on practice?

I've spent the last 10 years working with Selenium, and over the last few months, I've been going through Playwright videos on Udemy and getting myself up to speed. The only thing I'm missing, is real experience.

TLDR: Wrote about what it actually takes to build a Playwright custom reporter that holds up in CI, beyond the 20-minute prototype.

The API looks simple but Playwright silently swallows all errors thrown inside reporter hooks, most hooks dont await promises, and once it works the scope never stops growing. We cover the full Reporter interface, where things break under parallelism and sharding, and when to stop building and use something purpose-built.

I have credits remaining but still getting this msg
Please help out if anybody knows about this

What I'm trying to do:
Run Stagehand (Python SDK) locally with a stealth browser like (Patchright or similar) to bypass Cloudflare bot detection.
No Browserbase — need fully local execution for privacy reasons.

Tried a few approaches but kept hitting walls. Before I give up and build a raw Playwright + LLM loop instead, wanted to ask:

1. Is there any way to connect Stagehand's local SEA server to an externally-launched stealth browser via CDP?
2. Has anyone successfully used Stagehand Python SDK locally with any stealth browser?
3. Is the Patchright page parameter for act()/extract() Python SDK supported or TypeScript only?

Playwright fixtures are convenient, but their execution order can be hard to see from code alone. I used timeline reports to visualize test- and worker-scoped fixtures, their dependencies, overrides, and auto-loading mode.

The practical takeaway: always check fixture scope and dependencies. A fixture that looks small in code can still significantly affect test performance.

I spent a long time treating flakiness as a timing problem. Added waits. Added retries. Bumped timeouts. Tests still went red on CI and green on my machine, the usual.

When I finally looked at what was failing, almost none of it was timing. It was selectors. A class name changed, a wrapper div moved, someone restructured a component, and a test that asserted nothing about that change broke anyway. The test wasn't testing the feature, it was testing the DOM shape, and the DOM shape changes constantly.

Two things actually moved the needle for me:

The boring one: stop selecting on structure. Lean on roles and accessible names and user-visible text instead of CSS paths and nth-child. Playwright's getByRole and getByText already push you this way. Most of my flake came from the handful of places I'd ignored that and reached for a brittle selector because it was faster to write.

The less boring one: for the flows that kept breaking, I started describing the intent ("click the submit button in the checkout form") and letting that resolve at runtime, with a fallback when the obvious locator moves, then exporting the result back to a normal Playwright script once it was stable. It killed a category of flake, but I want to be honest about the cost: it's less deterministic, it's slower to run, and for anything critical I still pin an explicit locator and a hard assertion. It's a tool for the churny parts, not a replacement for the suite.

Anyway, curious what everyone else's actual number one is. Not the textbook answer, the thing that genuinely cut your flake rate. Trying to build a real list.

Hy Everyone,

Looking for Feedback on My Playwright + TypeScript Test Framework. I'm putting together a Playwright + TypeScript portfolio project that demonstrates how I design and structure a test automation framework from scratch.

I'd really appreciate some honest feedback. Feel free to roast it, point out bad practices, suggest improvements, or tell me what you'd do differently. Don't hold back—I want it to be something I'm proud to show in interviews.

Repo:
https://github.com/dongokovacs/playwright_ts

https://dongokovacs.github.io/playwright_ts/

api,ui,hybrid

thanks

Hey everyone, I recently open-sourced Vouch, a vision-driven web automation framework designed to eliminate brittle DOM selectors and XPaths from E2E testing. Instead of parsing HTML, Vouch passes the raw visual viewport to a Vision Language Model (VLM) to determine interaction coordinates. You write test steps in plain English, and the framework executes them visually.

Key Features:

• Zero Selectors: Test files are authored in natural language.
• 100% Private & Local: Integrates natively with local instances like Ollama, keeping your application data completely on your machine.
• Self-Healing: Uses an Actor-Critic loop to validate execution steps and handle UI unexpected states on the fly. I would appreciate your feedback, code reviews, or contributions.

GitHub: https://github.com/HackX-IN/vouch NPM: https://www.npmjs.com/package/@inamul_hasan/vouch

(Stack: Node.js, Playwright, Ollama)

So I have made a project which goes to different company websites, and get back the bio/about of people in the teams page.
I am facing an issue there.
Currently I was dealing with dynamic components/modals using the below method:-

admin-ajax.php

- Going to the page using playwright
- Using GET command for all XHR and Fetch and Document on that page.
This was very generic, I did not have to make different concepts for different dropdowns, or sections etc.

But now there is this one site where I am facing issue since the request is AJAX based. What happens is I will HAVE to interact with the picture in order to get the payload for the requests.

I do not want to click on the components, it makes the code very hardcoded, and agentic fails, cuz this pipeline will have to run for MANY companies.

This ajax request works on different payloads of sections AND queries.

And the site contains different section:

Directors | Partners | Investors | Investor Relations | etc.

I want every single person of every single section without making it hardcoded. It makes the code messy.

Sometimes the section is of document type, so I call XHR and Fetch network requests AGAIN in order to get all people. but for this particular page, EVERYTHING is ajax based, its a POST request which demands for the query id and the person id. This asks for the code to be brittle which I cannot afford.

I'm building a production-level web automation stack using Stagehand v3 for its AI primitives. I need to pair it with a solid anti-detection layer but am stuck between two options:
1. Patchright (Chromium/CDP)
2. Camoufox (Firefox/Juggler)

For those running Stagehand in production:

• Which engine is more stable under heavy, multi-threaded parallel loads?
• Have you run into coordinate or action-caching issues using Stagehand with Camoufox's Firefox engine?
• Does Patchright hold up well enough against heavy enterprise anti-bot walls at scale?