Vibe Testing with Playwright: Write Tests in Plain English Using Claude AI (2026)

Vibe coding — the practice of describing software in natural language and letting an AI write the implementation — exploded in 2025. Andrej Karpathy named it, developers adopted it, and productivity benchmarks shifted. But one part of the development lifecycle was slow to follow: testing.

Writing Playwright tests manually is still time-consuming. You need to know the API, understand the page structure, craft the right locators, and maintain it all when the UI changes. For many teams, tests are the bottleneck that limits how quickly they can ship.

Vibe testing applies the same principle: you communicate your testing intent in plain English, and the AI handles the implementation. With Playwright and Claude AI connected via MCP Server, the output is not a rough draft you spend an hour fixing — it is working, idiomatic Playwright TypeScript that passes on the first (or second) run.

This guide covers what vibe testing is, how it works with Playwright specifically, how to set it up, and where its real limits are.

What Is Vibe Testing?

The term "vibe testing" comes directly from "vibe coding" — the idea that you work at the level of intent rather than implementation. In vibe coding, you tell an AI what you want the software to do, and it writes the code. In vibe testing, you tell an AI what you want to verify, and it writes the tests.

The practical difference from earlier AI test generation is the connection to reality. Early AI test tools generated code from static descriptions, producing tests full of made-up selectors that had to be corrected one by one. Vibe testing with Playwright's MCP Server gives Claude AI a live window into your application — it can navigate pages, read the real DOM, inspect element roles and labels, and generate tests using selectors that actually exist.

import { test, expect } from '@playwright/test';

test.describe('Login flow', () => {

  test('successful login redirects to dashboard', async ({ page }) => {
    await page.goto('https://staging.myapp.com/login');
    await page.getByLabel('Email address').fill('user@example.com');
    await page.getByLabel('Password').fill('correct-password');
    await page.getByRole('button', { name: 'Sign In' }).click();
    await expect(page).toHaveURL('/dashboard');
  });

  test('wrong password shows error message', async ({ page }) => {
    await page.goto('https://staging.myapp.com/login');
    await page.getByLabel('Email address').fill('user@example.com');
    await page.getByLabel('Password').fill('wrong-password');
    await page.getByRole('button', { name: 'Sign In' }).click();
    await expect(page.getByRole('alert')).toBeVisible();
    await expect(page.getByRole('alert')).toContainText('Invalid email or password');
  });

});

Claude generated getByLabel('Email address') and getByRole('button', { name: 'Sign In' }) because it read the real page through MCP and found those exact labels and roles. No guessing. No placeholder selectors to replace.

Vibe Testing vs. Traditional Test Writing

Here is how the two approaches compare on the tasks that consume the most engineering time:

The net result for most teams: vibe testing gets you to 70–80% coverage in a fraction of the time. The remaining coverage — nuanced business logic, security edge cases, complex state machines — still benefits from experienced engineers writing tests by hand. Vibe testing does not replace engineering judgment. It removes the hours of boilerplate so that judgment goes further.

Why MCP Makes Vibe Testing Work

The key ingredient that separates vibe testing from earlier "AI generates tests" tools is live application access via the Model Context Protocol (MCP).

When you connect Claude AI to Playwright via the MCP Server, Claude is not working from a static description of your UI. It can:

• Navigate to any URL in a real Playwright-controlled browser
• Read the page's ARIA snapshot — every role, label, and accessible name
• Take screenshots and reason about visual state
• Click elements, fill inputs, and observe what happens next
• Inspect network requests and console errors

This live context is why vibe testing produces getByRole('button', { name: 'Sign In' }) instead of document.querySelector('#loginBtn'). Claude uses what it can actually see, not what it guesses might exist.

Setting Up Vibe Testing with Playwright and Claude

Step 1: Install Playwright

npm init playwright@latest

Choose TypeScript when prompted. This scaffolds your playwright.config.ts, a sample test, and the browser binaries you need.

Step 2: Configure the Playwright MCP Server

Add the Playwright MCP Server to your Claude AI tool configuration. In Claude Code, this is done via the MCP settings:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Once configured, Claude Code gains a set of browser tools: navigate, click, fill, screenshot, snapshot, and more. Full step-by-step instructions are in the MCP Server setup guide.

Step 3: Start Your Application

Run your app locally or point Claude at a staging URL. Vibe testing works against any live, accessible URL — localhost, staging, or even production (read-only flows).

npm run dev   # Start your app at localhost:3000

Step 4: Describe Your Test Intent

Open Claude Code (or any Claude AI interface with MCP configured) and describe what you want to test. Be specific about the URL, the user action, and what you expect to happen. You do not need to know any Playwright API.

Claude navigates to the page via MCP, reads the form fields (their actual labels and roles), generates both test cases, and returns a complete .spec.ts file you can drop straight into your tests/ directory.

Step 5: Review and Run

npx playwright test signup.spec.ts --headed

Run with --headed the first time to watch the tests execute and catch any issues visually. Once they pass, remove --headed and add to CI.

Real Vibe Testing Examples

E-commerce: Cart and Checkout

test('add product to cart and verify order summary', async ({ page }) => {
  await page.goto('/products/laptop');
  await page.getByRole('button', { name: 'Add to Cart' }).click();
  await expect(page.getByRole('status')).toContainText('Added to cart');

  await page.goto('/cart');
  await expect(page.getByRole('row', { name: /laptop/i })).toBeVisible();
  await expect(page.getByTestId('cart-quantity')).toHaveText('1');

  await page.getByRole('link', { name: 'Proceed to Checkout' }).click();
  await expect(page.getByTestId('order-total')).toContainText('$');
});

SaaS: Onboarding Flow

Claude reads each step's form fields via MCP as it navigates through the wizard, generating accurate getByLabel() and getByRole('radio') selectors for every input rather than guessing at data-testid values.

Content Site: Search and Filtering

Three test cases from one natural language paragraph. No Playwright knowledge required to author the intent — only to review the output.

When Vibe Testing Works Best

Vibe testing delivers the highest return in these scenarios:

• New feature coverage: A PR lands with a new user flow. Describe it in a prompt, get tests before the sprint ends.
• Regression suite building: You have untested legacy flows. Point Claude at each page in turn and describe what should happen. Cover 50 flows in a day instead of a week.
• After UI redesigns: Selectors are broken everywhere. Re-run your vibe testing prompts against the new UI instead of hunting down every stale locator.
• Cross-browser coverage: Once you have a vibe-tested spec file, Playwright runs it across Chromium, Firefox, and WebKit automatically. The vibe testing investment multiplies across browsers.
• Non-engineer test authoring: QA analysts or product managers describe the test scenarios; engineers review the AI output. The bottleneck shifts from test writing to test review — a much faster process.

When to Write Tests by Hand

Vibe testing is not the right tool for everything. Hand-craft tests when:

• Complex authentication: OAuth flows, MFA, SSO with third-party IdPs, or session token manipulation require precise control that exceeds what a natural language description can convey.
• Exact business logic validation: If a discount calculation has edge cases in how it rounds fractions of a cent, you need an engineer who understands the algorithm to write and verify the assertions.
• Test fixtures and factories: Setting up complex database state (many-to-many relationships, cascading permissions) requires code that a vibe prompt cannot express precisely enough.
• Security testing: SQL injection, XSS, CSRF, and authentication bypass tests need deliberate adversarial intent — not natural language descriptions of normal flows.
• Performance thresholds: "The page should load in under 2 seconds under 200 concurrent users" is a load test, not a Playwright end-to-end test.

Vibe Testing + Playwright Agents: The Full Picture

Vibe testing handles test creation. Playwright test agents handle test maintenance. Together, they form a complete AI-powered testing workflow:

• Vibe testing (Claude + MCP): You describe a flow → Claude writes the test. Used at sprint start, after new features, after redesigns.
• Playwright agents (npx playwright init agents --loop claude): The Healer agent monitors your CI runs, detects failing tests, and patches broken locators automatically. Used continuously in CI/CD.

Run npx playwright init agents --loop claude to activate the agents layer on top of your existing Playwright project. From that point, vibe-generated tests are protected by autonomous healing — the AI writes them and the AI maintains them.

What Claude Gets Right (and Wrong)

Consistently right

• Using getByRole(), getByLabel(), and getByText() — the most resilient Playwright locators
• Proper async/await throughout, no unresolved promises
• expect(...).toBeVisible() and expect(...).toHaveURL() for navigation assertions
• Correct test.describe grouping and individual test() blocks
• Import statements and TypeScript types

Watch carefully

• Test data: Claude uses placeholder values like 'user@example.com' and 'correct-password'. Replace with test fixtures or environment variables before CI.
• Dynamic content: For dashboards with real-time data, Claude may assert on specific values that change. Review assertions on variable content.
• Popup / modal timing: Claude occasionally misses that a modal must be dismissed before the next step proceeds. Add await expect(modal).toBeHidden() gates where needed.
• Multi-tab flows: Tests that open new tabs require explicit page.waitForEvent('popup') handling. Prompt Claude explicitly if your flow opens new tabs.

Frequently Asked Questions

Meet Your Instructor

Asim Noaman

Senior QA Automation Engineer & AI Testing Specialist

With years of hands-on experience building test automation frameworks for production applications, Asim specializes in combining traditional QA methodologies with cutting-edge AI tools. He has helped teams adopt Playwright and AI-driven testing workflows to ship faster with fewer bugs.

Udemy Instructor Published course author

Playwright + AI Expert Specialized in AI-powered QA

Production Experience Enterprise-grade frameworks

Connect on LinkedIn