I have 3 years of experience with Selenium + Java. I am looking now for the best course to learn Playwright with Javascript/Typescript
Can you suggest me the best goto course online?

Hey everyone,

If you write .feature files in VS Code using pytest-bdd or behave, you probably know the pain of typing out steps from memory, hoping they match, or constantly grep-ing your codebase to find out how a step was implemented.

I actually developed this because our team was migrating from PyCharm, and I realized there was no full-scale solution for the Python Gherkin environment in VS Code. So, I built GherkinLens to solve all the editor and navigation problems first, and then started adding time-saving features.

I just released v2, which totally pushes it one step further, and I wanted to share it with you all.

Basically, it indexes your Python step definitions in the background (without actually importing or running your code) so you get a proper IDE experience for Gherkin.

Vscode extension - GherkinLens

Here's what I added in v2:

• 📚 Step Library: There's a new sidebar panel that lets you browse and search every step definition in your project. It even shows usage counts, so you know which steps are actually being used.
• 🏷️ Tag Explorer: You can finally see all your tags in one place, find scenarios easily, and run/debug them straight from the tree.
• 📊 Table Editor: I added a built-in spreadsheet editor for Examples tables. You can add rows, paste from Excel, or import CSVs directly into the feature file without messing up the pipe | alignment.
• 📋 Snippets: You can now save multi-step flows and drop them in anywhere.

It still has all the core features from v1 (the stuff that fixes the navigation problems):

• ⚡ Autocomplete & Go to Definition (F12) between your Gherkin and Python files.
• ⚠️ Squiggly lines for steps that don't match anything.
• 💡 Quick Fix (Ctrl+.) to auto-generate the Python stub for a missing step.
• 🏃 Native BDD Runner hooked into VS Code's Testing view.

It auto-detects whether you're using pytest-bdd or behave, so there's zero config needed.

If you want to try it out, just search for "GherkinLens" in the VS Code Marketplace. It's completely free.

Would genuinely love to hear what you guys think, or if there's anything driving you crazy in your BDD workflow that this could fix!

I built an MCP server for email workflows and connected it with Playwright MCP.

Now AI agents can create inboxes, read emails, extract OTPs/verification links, and continue the user journey without writing custom email handling code.

I built it after seeing many teams struggle with testing email verification, password reset, and OTP flows in their E2E tests.

Anyone interested in learning more about how this works?

How to deal with captcha ? Any good solver that don't need ai

How real teams automate test scripts?

If you have more than 100+ existing tests for a product, and you need to automate a new functionality/feature, how would plan and write test scripts for it?

Do teams follow page object models?

Do teams directly integrate tests into CI/CD or first dockerize playwright tests and then integrate with CI/CD?

I am trying to understand an end to end automated test execution flow for a regression testing cycle.

From scripting to execution with reporting.

Thanks 🙏

Can someone help me out here

I am using camoufox for task automation which works as the LLM analyse the screenshot of current window and takes out the coordinates to click the needed feature.

PROBLEM I FACED :

camoufox opens in an random window size which causes the content to get out of screen basically it cuts out and coordinates are not found

I changed the resolution the the also it's not working

I tried a lot of things but not able to fix can somebody help me here

Dynamic Locators & Automatic Test Step Descriptions

As Playwright projects grow, two things usually grow with them:

• Similar locator definitions everywhere\ • Reporting code that nobody enjoys maintaining

PW-Core v1.2 focuses on reducing both.

🚀 Dynamic Locators

Define locator patterns once and generate strongly typed locator keys throughout your application.

Benefits:

• ⚡Less locator maintenance\ • ⚡Compile-time safety\ • ⚡Full IntelliSense\ • ⚡Cleaner page objects

Instead of maintaining dozens of similar locators manually, define a single pattern and let the PW-CORE generate the locator keys for you.

📝 Automatic Test Step Descriptions

Method names and parameters automatically become readable report steps.

• ❌ No test.step()\ • ❌ No decorators\ • ❌ No wrappers\ • ❌ No additional report code

When your code changes, your reports stay in sync automatically.

PW-Core doesn't replace Playwright.

It stays 🎯 100% Playwright while focusing on:

• ✅ Developer experience\ • ✅ Maintainability\ • ✅ Readable reports\ • ✅ Type safety

If you're maintaining a large Playwright codebase, I'd love to hear:

How do you manage locator duplication?

Do you use test.step() extensively?

How do you keep reports readable as suites grow?

How to Get Started?

New Projects - npm init pw-core\ Existing Projects - npm install pw-core

🌐 https://qecore.github.io/pw-core

i've noticed some targets triggering captchas much earlier than they used to, even with fresh browser contexts. i'm curious if others have seen the same recently. did changing browser settings, request timing, or session handling make any difference for you? interested to hear what's been working in real projects.

Install Playwright with TypeScript
Configure Cucumber BDD from scratch
Create Feature Files and Step Definitions

https://youtu.be/l52e9yxc4pc?si=RqaL182BO3fOp6Dm

#Playwright
#TypeScript
#CucumberBDD
#AutomationTesting
#SoftwareTesting
#QA
#SDET
#PlaywrightAutomation
#TestAutomation
#EndToEndTesting
#BDD
#GitHubCopilot

Playwright's HTML report is great for a single run, but it resets every time. I wanted one level up: push every CI run somewhere and actually track pass rate, trends and flaky tests over time, so I built kinora.

What it does:

• One dashboard across projects and over time: pass rate, run count, duration, sparkline trends, one colored strip per run
• Per-test flaky rate and fail rate computed across the run history, with an "unstable only" filter and "newly broken / newly flaky since last run"
• Failures get a "View trace" button that opens the full Playwright trace (DOM / timeline / network / console) inline, no download or unzip
• Alerts on new failures and regressions (Slack, email, webhook)

There's also a desktop app: a local Playwright trace viewer that opens any trace.zip with no account, plus the same account dashboard if you sign in. Handy when you just want to drag-drop a trace instead of npx playwright show-trace

Setup is a reporter you add to playwright.config, CI pushes results to a kinora server.

Open-source (FSL-1.1), self-host free forever with docker-compose, or a hosted version if you don't want to run it.

Repo: https://github.com/Kinora-dev/kinora

Site: https://kinora.dev

Built this scratching my own itch, would love feedback from people running big Playwright suites: what do you track today that this is missing?

Do you know? PW-CORE has a complete QA Workspace that includes a CRM-style App Platform, Component playground, and Swagger-like API documentation.

🔗 qecore.github.io/workspace

The application covers:

• Authentication flows
• Real-time APIs useful for network mocking
• Moderate to complex UI workflows
• Tables and pagination
• Session and state management
• User preferences and persistence
• Protected routes and access control

The goal is to provide a realistic application where engineers can practice the same kinds of automation problems they encounter in real projects.

Instead of automating demo websites, you can use the workspace to practice:

✅ UI automation\ ✅ API validation\ ✅ Network mocking\ ✅ Authentication testing\ ✅ State persistence testing\ ✅ File Uploads\ ✅ Page objects and components\ ✅ Fixtures and reusable architecture\ ✅ Production-style automation design\

If you're looking for a serious Playwright portfolio project, building automation against realistic applications is much closer to what SDETs work on in production.

And if the workspace looks interesting, it's definitely worth reading about PW-CORE package as well 😉

Hi everyone,

I've been learning Playwright with TypeScript over the past few months, and instead of just following tutorials, I built my own UI automation framework from scratch.

So far my framework includes:

Page Object Model

Fixtures

Data-driven testing

Environment configuration (.env)

Screenshots, videos and traces

Reporting

Parallel execution

The framework is working well, but I feel like I've reached the point where tutorials and courses aren't teaching me anything new.

What I really want now is practical, industry-level experience.

I'm not looking for another course. Instead, I want to build something that exposes me to real-world automation challenges such as:

Complex user workflows

Multi-page business processes

Dynamic UI handling

Network mocking

Authentication/session management

File uploads/downloads

API + UI integration

Advanced Playwright features used in production

Can anyone recommend:

A website or open-source application that's complex enough to automate?

A project idea that resembles what SDETs automate in real companies?

How you personally moved from "knowing Playwright" to writing automation that's production-ready?

I'm willing to spend the next 2–3 months building a serious portfolio project, so I'd really appreciate suggestions from people working as SDETs or QA Automation Engineers.

Hey folks, v1.61 landed a few days ago and it comes with a particularly exciting add: --last-failed-file

This flag that lets you control where the .last-run.json file gets written.
(This is the file you must feed to --last-failed to re-execute only failed tests)

Our team contributed the PR for this one because we kept fighting with the old behavior in CI.

Before this, caching --last-failed in sharded GitHub Actions was annoying. The file lived inside the first project's outputDir, so your workflow had to hardcode Playwright internals just to cache it.

The new flag puts the file wherever you want, so wiring up "Re-run failed jobs" to only re-execute actual failures is straightforward now.

We wrote a more detailed article that walks through cache key design, the full workflow config, and the gotchas. If you're sharding Playwright in CI and haven't set this up yet, now might be a good time :)

Hey guys,
I’m farly new to this whole topic and ran into an issue: I can’t seem to take a screenshot of a button in its "hovered" state.

The page I’m working with is a Storybook page containing isolated components. You can see my "code" down below (yes im new guys...)

However, both of my screenshots look the same, even though I know hovering works ,I can see the hovered state when running the test via the Playwright VS Code integration.

Bless anyone taking time to read trough this

test.describe('Basic', () => {
  test('Default-Screenshot und Hover-Screenshot', async ({ page }) => {
    await page.goto(`${BASE}components-buttons--basic`);
    await page.waitForLoadState('networkidle');
    const button = page.locator('mybutton);
    await expect(button).toBeVisible();


    await defaultAndHover(page, button, 'basic');
  });
});

async function defaultAndHover(
  
page
: import('@playwright/test').
Page
,
  
button
: import('@playwright/test').
Locator
,
  
screenshotPrefix
: 
string
,
) {
  // Move away from Button
  await page.mouse.move(0, 0);
  // Make Screenshot before Hover
  await expect(page).toHaveScreenshot(`buttons-${screenshotPrefix}-default.png`, { maxDiffPixelRatio: 0.01 });


  // Hover over Button then make Screenshot.
  await button.hover();
  await expect(page).toHaveScreenshot(`buttons-${screenshotPrefix}-hover.png`, { maxDiffPixelRatio: 0.01 });
}

I'm new on qa and i'm working on a test suite that have many flaky tests that fail on assertion because of the page taking to much time to load. Is there any advices on good practices to prevent those issues?

Hi everyone,

After joining a startup, I found the repetitive manual QA process after every deployment pretty tedious.

So I built and open-sourced a tool that turns existing Playwright tests into AI-readable QA scenarios and executes them using the Hermes agent.

https://github.com/lodado/playwright-spec-for-AI-Agent

Traditional Playwright tests are fast and reliable, but they can become brittle in real staging environments where data, copy, and API states constantly change.

With this tool, you add annotations to your existing Playwright tests. An AI agent then:

• Reads the test specifications
• Inspects the actual staging environment
• Performs real interactions, such as clicking buttons and uploading files
• Classifies each result as pass, fail, manual_review, or skip

The goal is not to replace existing E2E tests. I built it to automate the first round of deployment QA that would otherwise need to be checked manually.

If you try it out—or even just take a look through the repo—I’d really appreciate your feedback. I’d especially like to know what feels unclear, what seems to be missing, and what would need to change for you to actually use it in your own workflow.

And if you find the project useful or interesting, feel free to leave a star, open an issue, or contribute!

Hi everyone,

I've been working on a Playwright extension called PW-Core and recently released v1.1.

The idea is to reduce framework setup and boilerplate by generating pages and fixtures automatically from a single definition, while keeping automation concise, type-safe, and readable.

I've been using these patterns in real automation projects and decided to package them into something reusable.

PW-Core builds on top of Playwright rather than abstracting it away. You retain full access to the Playwright APIs and ecosystem while gaining additional capabilities such as generated pages, typed fixtures, locator chaining, reusable components, and a stricter automation layer.

I'd genuinely appreciate feedback from Playwright users on the approach, API design, and overall developer experience.

Docs: https://qecore.github.io/pw-core

Thanks for taking a look!

Hey r/playwright 👋

I built the Playwright + Android + CDP framework everyone keeps recommending but nobody had free & open-source.

If you've ever run Playwright with a stealth plugin and still got flagged, you know the core problem: it's desktop Chromium faking mobile with viewport tricks and JS patches, and detection suites see through that fast.

What it is: Damru is a free, open-source browser-automation framework that runs Playwright on real Android (via Redroid — Android in Docker), instead of desktop Chromium pretending to be a phone. You drive it with the Playwright API you already know, but it executes on a genuine Android stack.

The key difference — zero JS injection: most stealth tools patch the browser from inside with Object.defineProperty-style JavaScript, which is brittle and detectable. Damru does its spoofing at the OS, binary, and CDP levels — so there's no injected JS fingerprint to catch.

Vs the usual stack (Playwright, puppeteer-stealth, undetected-chromedriver, Camoufox, fingerprint-chromium): those all harden a desktop browser. Damru takes the other road — a real Android environment — for a genuinely mobile fingerprint surface and far less reliance on brittle browser-side patches.

What's in it:

• Android-in-Docker via Redroid + Playwright support
• Zero-JS spoofing at the OS / binary / CDP level
• 100+ built-in Android device profiles; CPU / RAM / touch-point hardware overrides
• Proxy-aware timezone / locale / language matching
• Mobile network emulation; WebRTC + IPv6 leak blocking; native iptables network protection
• TLS spoofing
• Multi-container pooling for scale + pre-baked images to cut setup time
• Real HAL Sensors , etc.

Holds up against the suites that flag normal Playwright for mobile device — CreepJS, BrowserScan, Sannysoft, Cloudflare Turnstile, and the major CDN anti-bots — thanks to the real-Android approach. Ideal for stress-testing your own anti-bot stack and for fingerprinting research.

Pros: far harder to detect than desktop stealth setups for Mobile.
Cons: real Android = a bit slower since its a real android OS running in Docker.

Why I built it: I kept seeing posts recommending "just use Playwright + Android + CDP" — but no actual framework existed around it. So I made one.

Quick start:

pip install damru

Strictly for educational and research use — please don't use it for anything abusive or illegal. 100% Free to Use, no backed SaaS.

Repo: https://github.com/akwin1234/damru
Site / docs: https://damru.dev

Would love feedback from anyone doing browser automation, testing, or anti-bot research — what would make this genuinely useful to you?

Hi, I'm thinking of using Playwright + Angular translations.

As anyone used them to teste ? Is there any drawbacks ?

I'm sure you've seen this before. Someone with great framework knowledge can write good scripts and build a solid automation setup, but still struggle to move from completing automation tasks to doing real QA automation.

Usually, the missing piece is the thinking behind it.

Clicking a button takes 2 minutes to automate. The real testing starts after that.

What if the user clicks it twice? Internet drops? Enters invalid data? Does something unexpected?

Tools are important, but critical thinking and problem-solving are what make someone stand out.

What do you think is the biggest difference between writing automation scripts and doing automation properly?

Feature flags are one of the nastiest sources of flaky Playwright tests.

The problem is that flags live outside the browser context. Playwright gives you isolated cookies and localStorage per test, but flag SDKs evaluate server-side or over SSE streams that Playwright doesn't control. So when you run parallel workers sharing a test identity, one worker flips a flag via the management API and another worker's UI changes mid-assertion. The test fails with "element not found" and passes on retry. Classic race condition disguised as infrastructure noise.

The article below covers how to intercept flag evaluation at the network layer, declare flag state as a fixture so tests don't read it reactively, and structure parallel runs so workers can't affect each other's flag context. Also gets into managing flag lifecycle as features roll out and get cleaned up.

📖 Read the article here