DEV Community: Srikanth Srinivas

Playwright Studio from AIQEAcademy

Srikanth Srinivas — Sat, 11 Apr 2026 02:26:21 +0000

Playwright Studio is a Chrome DevTools extension that lets you record interactions, add assertions, save tests with version history, and run them headlessly — all from inside DevTools. No terminal. No setup. No copy-pasting from codegen.

The Problem With Existing Tools

playwright codegen is excellent for a quick start. But it has real limitations in daily use:

It opens a separate browser window — breaking your authenticated session
Generated code needs manual cleanup before it's mergeable
There's no way to add assertions interactively
Nothing is saved — it's a one-shot dump to stdout

For teams doing continuous authoring — adding coverage as features ship — you need something embedded in your workflow. That's what Playwright Studio is.

What It Does

The extension lives in your Chrome DevTools panel. Here's the core loop:

1. Record

Click Record and interact with the page normally. The extension captures:

page.goto() calls from navigation
page.click() with Playwright-native locators (preferring getByRole, getByLabel, getByText over brittle CSS selectors)
page.fill() for inputs
page.selectOption() for dropdowns
page.check() / page.uncheck() for checkboxes

Every captured action generates idiomatic Playwright code in real time — you see it build line by line in the panel.

// Example of what gets generated:
import { test, expect } from '@playwright/test';

test('User login flow', async ({ page }) => {
  await page.goto('https://myapp.com/login');
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Password').fill('••••••••');
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page).toHaveURL('/dashboard');
  await expect(page.getByRole('heading', { name: 'Welcome' })).toBeVisible();
});

2. Assert

Right-click any element while recording and add assertions:

Assertion	Generated Code
Visible	`await expect(locator).toBeVisible()`
Has text	`await expect(locator).toHaveText('...')`
URL matches	`await expect(page).toHaveURL('...')`
ARIA role	`await expect(locator).toHaveRole('button')`
Count	`await expect(locator).toHaveCount(3)`

No manual expect() wiring. You pick the element, pick the assertion type, and it slots into the generated test at the right position.

3. Save

Tests are saved inside the extension with:

Name and tags for organization
Version history — every edit creates a new version, old ones are preserved
Selector tracking — the extension records which locators were used so you can spot fragility early
Metadata — source, timestamp, test status

4. Run

Hit Run and the test executes headlessly inside Chrome using the Playwright runner bundled with the extension. Results come back as a step-by-step pass/fail report — no terminal needed.

5. Export

One click exports a clean .spec.ts file. Drop it into your existing Playwright project. It works.

Architecture

The extension is built on Chrome's Manifest V3 with three layers:

┌──────────────────────────────────────────────┐
│  DevTools Panel (React)                       │
│  Recording UI · Test editor · Result viewer   │
└────────────────────┬─────────────────────────┘
                     │ chrome.runtime.sendMessage
┌────────────────────▼─────────────────────────┐
│  Background Service Worker                    │
│  State management · Test storage · Runner     │
└────────────────────┬─────────────────────────┘
                     │ chrome.scripting.executeScript
┌────────────────────▼─────────────────────────┐
│  Content Script                               │
│  DOM event capture · Selector generation      │
└──────────────────────────────────────────────┘

Selector Strategy

The hardest part of any recorder is generating selectors that don't break the moment someone renames a CSS class. Playwright Studio uses a priority-ordered strategy:

getByRole() — if the element has a semantic ARIA role and accessible name
getByLabel() — for form inputs bound to a <label>
getByText() — for elements with stable visible text
getByTestId() — if data-testid is present
locator('css=...') — last resort, flagged as potentially fragile

Each selector is stored alongside fallbacks, laying the groundwork for self-healing in a future release.

Test Runner

Running tests from inside the extension uses a sandboxed execution context. The generated Playwright script is evaluated with:

Action replay against the live page
Step-level timing capture
Console log collection
Screenshot on failure

What's Coming Next

Playwright Studio v1 covers the core authoring loop. The roadmap includes:

Cloud sync — push tests from the extension to a cloud backend, run them remotely with full parallel execution across Chromium/Firefox/WebKit
AI assertion generation — right-click an element and Claude suggests the most meaningful assertion based on context
Self-healing selectors — when a selector breaks, the extension proposes a fix based on the updated DOM
Visual regression — capture baseline screenshots and diff them on every run
MCP integration — expose tests to AI agents (Claude, Cursor, VS Code Copilot) via the Model Context Protocol

Try It

https://chromewebstore.google.com/detail/playwright-studio-by-aiqe/eodfkbagoeghobkkfpcfpacnnpgidhhd?authuser=0&hl=en

Platform: aiqeacademy.onrender.com
Early access: Drop a comment or reach out directly

If you're building test automation tooling, working on Chrome extensions, or just have opinions about Playwright selector strategies — I'd love to hear from you.

Playwright Series #1 — What Is Playwright and Why It Beats Everything Else

Srikanth Srinivas — Thu, 09 Apr 2026 01:06:08 +0000

This article was originally published on
AIQEAcademy

What Is Playwright?
Playwright is an open-source browser automation framework built by Microsoft. It lets you write tests that control a real browser — clicking buttons, filling forms, navigating pages — exactly as a real user would.

What separates Playwright from everything that came before it:

All browsers, one API — Chromium, Firefox and WebKit (Safari engine) from a single test file
Auto-waiting — no more sleep(2000) hacks; Playwright waits for elements to be ready before acting
Network interception — intercept, modify or mock any HTTP request from your tests
Parallel by default — tests run in parallel across multiple workers out of the box
Tracing — record a full video, screenshot timeline and network log of every test run
Why Not Selenium?
Selenium is 20 years old. It works, but it was designed in an era of synchronous web apps. You feel that age:

Feature Selenium Playwright
Auto-waiting ❌ Manual WebDriverWait ✅ Built-in everywhere
Network mocking ❌ Requires proxy setup ✅ Native page.route()
Parallel execution ❌ Grid setup required ✅ Built-in workers
Trace viewer ❌ None ✅ Full timeline recorder
Setup time Hours Minutes
Flakiness High Low
Why Not Cypress?
Cypress solved many Selenium problems but introduced its own constraints:

No multi-tab support — Playwright handles multiple tabs and windows natively
No cross-browser — Cypress only supports Chromium-based browsers and Firefox (no Safari)
No multi-domain — Cypress historically struggled with navigating across different origins in one test
JavaScript only — Playwright supports TypeScript, JavaScript, Python, Java and C#
Why Not WebdriverIO?
WebdriverIO is excellent and worth learning, but Playwright wins on:

Simpler setup (no separate driver management)
Better auto-waiting implementation
Native trace viewer
Faster test execution
Installing Playwright
You need Node.js 18 or higher. Check your version:

node --version

should output v18.x.x or higher

Create a new project and run the Playwright installer:

mkdir my-playwright-project
cd my-playwright-project
npm init -y
npm init playwright@latest
The installer asks a few questions:

✔ Do you want to use TypeScript or JavaScript? › TypeScript
✔ Where to put your end-to-end tests? › tests
✔ Add a GitHub Actions workflow? › false (we'll cover CI in Part 10)
✔ Install Playwright browsers? › true
Say yes to installing browsers. This downloads Chromium, Firefox and WebKit — about 300MB total. Only needed once per machine.

What Got Created
After installation your project looks like this:

my-playwright-project/
├── tests/
│ └── example.spec.ts ← sample test Playwright generates
├── playwright.config.ts ← all configuration lives here
├── package.json
└── node_modules/
Your First Look at playwright.config.ts
Open playwright.config.ts. The defaults are sensible, but let's understand the key parts:

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
// Where your test files live
testDir: './tests',

// Run tests in parallel
fullyParallel: true,

// Retry failed tests once in CI
retries: process.env.CI ? 1 : 0,

// Number of parallel workers
workers: process.env.CI ? 2 : undefined,

// Test timeout (30 seconds per test)
timeout: 30_000,

// Reporter — list in dev, HTML report in CI
reporter: [['list'], ['html', { open: 'never' }]],

use: {
// Base URL so you can write await page.goto('/login') instead of full URL
baseURL: 'http://localhost:3000',

// Capture trace on first retry
trace: 'on-first-retry',

// Take screenshot on failure
screenshot: 'only-on-failure',

// Run tests against these browsers
projects: [
{ name: 'chromium', use: { ...devices['Desktop Chrome'] } },
{ name: 'firefox', use: { ...devices['Desktop Firefox'] } },
{ name: 'webkit', use: { ...devices['Desktop Safari'] } },
],
});
Running the Sample Test
Run the sample test Playwright generated:

npx playwright test
You'll see output like:

Running 6 tests using 6 workers

✓ tests/example.spec.ts:3:5 › has title (1.2s)
✓ tests/example.spec.ts:3:5 › has title (chromium) (1.2s)
✓ tests/example.spec.ts:3:5 › has title (firefox) (1.8s)
✓ tests/example.spec.ts:3:5 › has title (webkit) (2.1s)
...

6 passed (5.3s)
All three browsers. No setup. No driver management. It just works.

Viewing the HTML Report
After the run, open the HTML report:

npx playwright show-report
This opens a browser with a full breakdown of every test, browser, timing and any screenshots.

The Playwright VS Code Extension
If you use VS Code, install the official Playwright extension:

Open Extensions (Cmd+Shift+X / Ctrl+Shift+X)
Search Playwright Test for VSCode (Microsoft)
Install
The extension gives you:

Run/debug individual tests with a click
Built-in test recorder (generate test code by clicking through a page)
Inline test results
Useful CLI Commands to Know

Run all tests

npx playwright test

Run a specific file

npx playwright test tests/login.spec.ts

Run tests matching a name pattern

npx playwright test --grep "checkout"

Run only on one browser

npx playwright test --project=chromium

Run in headed mode (see the browser)

npx playwright test --headed

Run in debug mode (step through tests)

npx playwright test --debug

Open the interactive UI mode

npx playwright test --ui

Generate a test by recording clicks

npx playwright codegen https://example.com
--ui mode is particularly useful — it's an interactive test runner that shows you the browser, lets you filter and rerun tests, and updates in real time as you save files.

Read more free tutorials at AIQEAcademy

Papio Framework Generator

Srikanth Srinivas — Sat, 14 Mar 2026 05:03:16 +0000

"Stop Writing Test Framework Manually — I Built a Chrome Extension That Does It For You (Playwright, Cypress, WebdriverIO, Selenium

If you've spent time in test automation, you know the selector problem.

You open DevTools, inspect an element, and then manually craft something like:
driver.findElement(By.xpath("//div[@class='container']//button[contains(text(),'Submit')]"))

Two sprints later, the UI changes. The class is gone. The test breaks. You fix it. The cycle repeats indefinitely.

After 20+ years in QA automation — working across Toyota Connected, Caesars Digital, and enterprise Fortune 500 environments — I decided to build the tool I always wished existed: Papio Selector.

What is Papio Selector?
Papio Selector is a Chrome DevTools extension that automatically generates production-ready test selectors for five major automation frameworks — simultaneously — from a single click on any element.

The Core Problem: Framework Fragmentation
Modern QA teams rarely use just one framework. You might have:
• Legacy Selenium tests from 2018
• New Playwright tests your team added last year
• Cypress for component testing
• WebdriverIO for mobile/cross-browser

Each framework has its own selector API. Maintaining consistency across all of them manually is error-prone and time-consuming. Papio generates idiomatic code for all of them from a single inspection.

Shadow DOM — The Elephant in the Room
Shadow DOM support is where most tools fail. Web components, Lit elements, Angular components using ViewEncapsulation — these all create shadow roots that standard CSS selectors can't pierce. Papio detects shadow roots automatically and generates the correct piercing selectors for each framework.

Selector Priority Algorithm
Not all selectors are equal. Papio uses a priority system that mirrors accessibility and maintainability best practices:

data-testid / data-cy attributes (most stable)
ARIA roles and labels
ID attributes
Unique CSS class combinations
Structural/positional selectors (last resort) This means Papio-generated selectors are inherently more resilient to UI changes than manually crafted ones.

Install & Try It
Available free on the Chrome Web Store. Search 'Papio Selector' or visit https://chromewebstore.google.com/detail/papio-test-framework-gene/blmnefcnhccikfcghoaphpnmfpffbknd
I'd love feedback from the Dev.to community — especially on edge cases, accessibility patterns, and framework-specific conventions I may have missed.

Srikanth | Senior Automation Architect | IEEE Senior Member | Creator of Papio Selector