Using ChatGPT to write Playwright tests (2026)

TL;DR

Give ChatGPT precise acceptance criteria, focused page evidence, and your Playwright conventions, then ask for a narrow test plus explicit assumptions. Run and review every locator and assertion, use traces for feedback, protect sensitive data, and merge only after normal engineering gates pass.

Key Takeaways

• Treat ChatGPT as a drafting and review partner while the SDET retains ownership of truth and release decisions.
• Provide focused requirements, application evidence, existing conventions, synthetic data, and explicit constraints.
• Verify every generated locator, assertion, wait, endpoint, helper, and fixture against the real project.
• Prefer user-facing locators, web-first assertions, isolated data, and observable outcomes over sleeps and positional selectors.
• Debug through exact errors, call logs, traces, and minimal changes instead of asking for broad rewrites.
• Apply the same lint, execution, security, review, and CI gates to AI-generated code as human-written code.

Using ChatGPT to write Playwright tests works best when the model acts as a drafting and review partner, not as an unverified test generator. Give it a precise behavior contract, relevant DOM or accessibility evidence, project conventions, and a runnable feedback loop. Then inspect every locator, assertion, wait, fixture, and data dependency before merging.

This 2026 guide presents a practical QA workflow for converting requirements into maintainable Playwright Test code. It includes reusable prompts, a runnable TypeScript example, locator and assertion review, network mocking, debugging, security precautions, and CI quality gates. The objective is faster engineering with the same accountability you apply to human-written automation.

TL;DR

Ask for one focused change at a time. Require Playwright Test APIs, role-based locators where appropriate, web-first assertions, no arbitrary sleeps, and an explanation of assumptions. ChatGPT can propose code, but only execution against the real application proves it works.

1. When Using ChatGPT to Write Playwright Tests Helps

Using ChatGPT to write Playwright tests is most valuable for reducing mechanical effort. It can turn acceptance criteria into a first test outline, explain unfamiliar APIs, convert brittle selectors into locator candidates, draft fixtures, identify missing negative cases, and summarize a trace or error log. These tasks benefit from patterns the model has seen, while remaining reviewable by an engineer.

It is less reliable when the necessary context is hidden. ChatGPT cannot know the live accessible name of a button, whether a spinner represents a committed transaction, which account is safe to use, or why a selector convention exists unless you provide that evidence. It may produce syntactically convincing code with an invented endpoint, stale API, weak assertion, or test that passes for the wrong reason.

Use the model for:

• Requirement decomposition and scenario brainstorming.
• First drafts that follow explicit team conventions.
• Explanations and targeted refactoring.
• Locator alternatives based on supplied markup.
• Negative, boundary, and accessibility test ideas.
• Review checklists and failure hypotheses.

Do not delegate release judgment, secret handling, production side effects, or final oracle design. Never paste credentials, customer data, private source code, or proprietary logs into a tool unless your organization's approved data controls allow it. Replace sensitive values with minimal synthetic examples.

The right mental model is pair programming. The engineer owns scope and truth, ChatGPT accelerates translation into code, and Playwright plus the application provide evidence.

2. Prepare the Playwright Project and Context

A model produces better code when it sees the project contract. Before prompting, collect the smallest relevant context:

• Playwright Test version from the lockfile.
• TypeScript settings and test directory.
• Existing configuration, fixtures, page objects, and naming style.
• Base URL and supported browser projects.
• Authentication and test-data strategy.
• Locator policy and available test IDs.
• Acceptance criteria and out-of-scope behavior.
• A focused DOM, accessibility, API, or trace excerpt.

Start a standard project with the official initializer or install Playwright Test in an existing Node project. The core commands are:

npm init playwright@latest
npx playwright test
npx playwright test --ui
npx playwright show-report

A compact configuration gives ChatGPT clear constraints:

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

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  forbidOnly: Boolean(process.env.CI),
  retries: process.env.CI ? 2 : 0,
  reporter: [['html', { open: 'never' }], ['list']],
  use: {
    baseURL: process.env.BASE_URL ?? 'https://demo.playwright.dev/todomvc',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  ],
});

Tell the model not to change configuration unless the task requires it. Otherwise a request for one test may return an unrelated framework redesign. Link to existing utilities rather than pasting the entire repository. Focused context reduces distraction and protects confidential material.

If the team is still choosing selectors, review Playwright getByRole locator patterns and when to use getByTestId before defining the prompt contract.

3. Write Prompts That Produce Reviewable Tests

A strong prompt describes role, task, evidence, constraints, and output. It also marks unknowns instead of inviting invention. Use this reusable template:

You are assisting with a Playwright Test suite in TypeScript.

Task:
Create one test for the acceptance criteria below.

Application evidence:
- Base URL: <test URL>
- Relevant accessible names or HTML: <focused evidence>
- Existing fixture imports: <exact imports>
- Test data: <synthetic data and cleanup rule>

Acceptance criteria:
1. <observable behavior>
2. <observable behavior>
3. <negative or boundary behavior>

Constraints:
- Use only current public @playwright/test APIs.
- Prefer getByRole, getByLabel, getByPlaceholder, or getByTestId.
- Use web-first expect assertions.
- Do not use waitForTimeout.
- Do not invent endpoints, test IDs, helpers, or credentials.
- Keep tests isolated and parallel-safe.
- If evidence is missing, list the assumption instead of coding it.

Return:
1. The complete test file.
2. Assumptions.
3. Why each assertion proves the requirement.

The final three requirements are important. Assumptions reveal gaps before code review. Assertion explanations expose tests that merely perform clicks. A request for current public APIs discourages invented helpers, although you still need to verify the code against installed documentation and TypeScript.

Iterate narrowly. Ask for a draft, run it, then provide the exact compiler error or trace observation. Do not ask the model to rewrite the whole suite after one locator fails. Narrow edits reduce accidental changes and make the diff reviewable.

For a code review prompt, include the test and team rules, then ask for findings ordered by correctness risk. AI code review for Playwright tests provides a deeper review workflow.

4. Generate and Run a First Maintainable Test

The TodoMVC example below is runnable against Playwright's public demo. It uses a user-facing placeholder, list-item roles, scoped locators, and web-first assertions. ChatGPT may draft something similar, but the engineer should run it and inspect whether every assertion proves intended behavior.

// tests/todo.spec.ts
import { test, expect } from '@playwright/test';

test.describe('todo lifecycle', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('/');
  });

  test('creates, completes, and filters a todo', async ({ page }) => {
    const newTodo = page.getByPlaceholder('What needs to be done?');

    await newTodo.fill('Review generated Playwright test');
    await newTodo.press('Enter');

    const todo = page
      .getByRole('listitem')
      .filter({ hasText: 'Review generated Playwright test' });

    await expect(todo).toHaveCount(1);
    await expect(todo).toContainText('Review generated Playwright test');

    await todo.getByRole('checkbox').check();
    await expect(todo).toHaveClass(/completed/);

    await page.getByRole('link', { name: 'Active' }).click();
    await expect(todo).toBeHidden();

    await page.getByRole('link', { name: 'Completed' }).click();
    await expect(todo).toBeVisible();
  });
});

Run just this file:

npx playwright test tests/todo.spec.ts --project=chromium

Review the generated draft before execution. Confirm imports, fixture names, URL behavior, locator availability, and assertion intent. Then run TypeScript, lint, and Playwright tests. If the test fails, use UI mode or a trace to inspect the actual page rather than guessing.

Notice what the test does not do. It does not hard-code a sleep, depend on item position, use a CSS chain tied to implementation details, or assert only that the final page contains some text. Each step has an observable outcome connected to the acceptance criteria.

When the real application has asynchronous persistence, add an assertion for the user-visible committed state or a documented response. Do not copy TodoMVC's immediate behavior into a different product without evidence.

5. Review AI-Generated Locator Strategy

Locators are a common source of plausible but brittle generated code. ChatGPT may invent a test ID, choose the first matching button, copy a long CSS path, or use text that changes by locale. Review locators as part of the test design, not as syntax.

Playwright recommends user-facing attributes and explicit contracts. A practical priority is contextual:

1. getByRole with an accessible name for interactive controls.
2. getByLabel for labeled form fields.
3. getByPlaceholder when placeholder is the real stable contract.
4. getByText for visible non-interactive content.
5. getByTestId for a deliberate test contract when user-facing attributes are ambiguous.
6. CSS or XPath only when the DOM structure is the intended stable interface.

Scope locators to a stable region or row. For example, find an order row by its visible ID, then locate the Refund button within that row. This is clearer than selecting the third button. Avoid first(), last(), or nth() unless position is itself the requirement. These methods can make strictness errors disappear while acting on the wrong element.

Ask ChatGPT to justify each locator against supplied evidence. If it proposes getByRole('button', { name: 'Save' }), verify the role and accessible name with the real application. Run codegen or inspect the accessibility tree for evidence:

npx playwright codegen https://authorized-test.example

Codegen is a locator discovery aid, not a substitute for test design. The engineer still selects the locator that expresses user intent and remains unique in the required scope.

6. Demand Meaningful Assertions and Reliable Waiting

Generated tests often click through a flow without proving the outcome. Another common defect is replacing uncertainty with waitForTimeout. Playwright actions already auto-wait for actionability, and web-first assertions retry until their condition is met or the assertion times out.

Prefer:

• await expect(locator).toBeVisible()
• await expect(locator).toHaveText(...)
• await expect(locator).toHaveValue(...)
• await expect(locator).toHaveURL(...)
• await expect(locator).toBeEnabled()
• await expect(locator).toHaveCount(...)

Use expect.poll for an external value that must be queried repeatedly, and expect.toPass only when a block of assertions genuinely needs retry behavior. Do not add them simply because a test is flaky. First find the missing product or synchronization contract.

Every assertion should answer, "Which requirement would fail if this assertion failed?" A URL check alone may not prove that an order saved. A toast may appear before persistence fails. Prefer a durable user-visible state, a documented API response, or a subsequent reload that proves persistence, based on the requirement.

Avoid assertions so broad that unrelated text satisfies them. Scope to the component or record. Avoid exact matching dynamic timestamps, random IDs, and generated prose unless they are the specified output. For dates, calculate expected values with the same timezone contract as the product, not the test runner's local assumptions.

When asking ChatGPT to fix a timeout, provide the call log and trace observations. A request that says only "make this stable" often produces a longer timeout, masking the defect. AI-assisted flaky test root cause analysis gives a more disciplined diagnostic approach.

7. Generate Fixtures, Network Mocks, and Test Data Carefully

ChatGPT can draft fixture and route code quickly, but lifecycle mistakes can leak state between tests. Tell it whether a fixture is test-scoped or worker-scoped, which resources it creates, and how cleanup works. Verify parallel execution and failure cleanup.

A current Playwright route mock can be simple:

// tests/profile.spec.ts
import { test, expect } from '@playwright/test';

test('shows a controlled profile response', async ({ page }) => {
  await page.route('**/api/profile', async route => {
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      json: {
        id: 'user-qa-101',
        displayName: 'QA Test User',
        plan: 'trial',
      },
    });
  });

  await page.goto('/profile');

  await expect(
    page.getByRole('heading', { name: 'QA Test User' })
  ).toBeVisible();
  await expect(page.getByText('Trial plan')).toBeVisible();
});

This code is valid only if the real application calls that endpoint and renders those values. The prompt must include the documented contract. Otherwise the model is guessing.

Use API setup or stable fixtures for test data instead of creating every prerequisite through the UI. Generate unique identifiers for parallel tests and delete records in teardown. Authentication state can be prepared once in a setup project when accounts and isolation rules support it, but never commit session state containing real credentials.

Mock at the boundary required by the test. A UI component test may mock the profile response. An end-to-end test should use the real authorized test service. If every test fulfills every route, the suite cannot detect integration defects.

Ask the model to label each mock and explain which risks it removes and which integration coverage it sacrifices. That forces a useful testing decision instead of defaulting to convenience.

8. Review Generated Code Like a Senior SDET

Treat AI-generated code as an external contribution. Read the entire diff. Search for invented helpers, disabled tests, focused test.only, broad catches, swallowed assertions, hard-coded secrets, arbitrary timeouts, destructive URLs, and changes outside the requested scope.

Use this review sequence:

1. Requirement: Does the scenario match the acceptance criteria and risk?
2. Oracle: Would the test fail if the product behavior were wrong?
3. Locator: Does each locator represent a stable, unique user or test contract?
4. Synchronization: Does it rely on Playwright waiting and observable state?
5. Isolation: Can it run alone, repeatedly, and in parallel?
6. Data: Is setup deterministic, synthetic, and cleaned up?
7. Security: Are secrets absent and side effects restricted to the test environment?
8. Maintainability: Is duplication justified or better expressed as a fixture or helper?
9. Diagnostics: Will a failure show enough evidence through trace, screenshot, and message?
10. Execution: Did lint, type checking, and the relevant browser run pass?

Reject tests that pass without exercising the target behavior. Mutation is a useful thought experiment: if the Save action did nothing, would the assertion catch it? If the API returned another user's record, would the test notice? If not, improve the oracle.

Do not accept a page object only because the model suggested one. Extract abstractions after repeated behavior and a stable interface are visible. Premature page objects can hide weak locators and create a second API nobody designed.

9. Debug and Refactor With an Evidence Loop

When a generated test fails, collect evidence before prompting again. Provide the exact error, Playwright call log, relevant trace observations, locator count, browser, configuration, and minimal code. Redact tokens and user data.

Use a diagnostic prompt:

Diagnose this Playwright Test failure.

Evidence:
- Exact error and call log: <paste>
- Browser and config: <paste relevant lines>
- Relevant test: <paste minimal test>
- Trace observation: <what the page actually showed>
- Locator count or accessibility evidence: <paste>

Return:
1. The most likely root cause and evidence.
2. Two alternate hypotheses.
3. The smallest code change for the primary cause.
4. A verification step.
Do not increase timeouts unless the evidence proves the product needs more time.

Run the smallest change and compare the trace. Continue until the root cause is proven. If the product is defective, keep or adapt the test as evidence and report the application defect. Do not rewrite the assertion to match wrong behavior.

For refactoring, ask ChatGPT to preserve behavior and output a narrow diff. Run tests before and after. Fixture extraction, shared login, or locator cleanup can change lifecycle and parallelism even when the code looks equivalent.

Keep useful prompts in the repository beside engineering documentation, not copied blindly into tests. Version team rules such as locator preference, data setup, accessibility expectations, and prohibited patterns. This turns individual prompting skill into a repeatable workflow.

10. Scale Using ChatGPT to Write Playwright Tests in CI

Using ChatGPT to write Playwright tests changes authoring, not the definition of done. Generated code should pass the same lint, type, test, security, and review gates as any other code. Do not create a weaker path for an AI-authored commit.

A practical pipeline runs:

npm ci
npm run lint
npx playwright test --project=chromium

Add cross-browser projects according to product risk, not because a prompt generated them. Preserve HTML reports and traces on failure. Run the launch or integration suites required by the repository. Keep credentials in the CI secret store and scope them to test-only accounts.

Track outcomes that reveal whether the workflow helps: review findings per generated test, first-run compile rate, escaped defects, flaky-test rate, maintenance changes, and time from requirement to trusted coverage. Do not measure success by lines of generated code. More low-value tests slow the suite and create false confidence.

Create a small approved prompt library for common tasks: acceptance criteria to draft, locator review, assertion review, negative-case brainstorming, failure diagnosis, and safe refactoring. Each prompt should require assumptions and prohibit invented application contracts.

Finally, sample generated tests for deeper review. Look for repeated weaknesses across the team, then update examples, lint rules, fixtures, or prompt guidance. The strongest improvement often comes from better application testability, accessible names, stable test IDs, and deterministic APIs, not from a longer prompt.

Interview Questions and Answers

Q: What are the main risks of using ChatGPT for Playwright tests?

The model can invent locators, endpoints, helpers, and assertions or use a valid API in the wrong context. It also lacks live application state unless evidence is provided. I mitigate this with focused context, explicit constraints, narrow diffs, execution, trace review, and normal code-review gates.

Q: How do you prompt ChatGPT for a stable locator?

I provide the relevant accessible names or focused HTML and state the team's locator policy. I ask for alternatives and a justification, while prohibiting invented test IDs and positional selectors. I verify uniqueness against the real page.

Q: Why should generated tests avoid waitForTimeout?

A fixed sleep guesses when the application will be ready, slows fast runs, and may still fail on slow runs. Playwright actions and web-first assertions wait for observable conditions. I identify the actual readiness contract and assert it.

Q: How do you verify an AI-generated assertion is meaningful?

I map it to an acceptance criterion and ask whether the test would fail if the feature were broken. I prefer durable outcomes over incidental UI signals. I also scope the assertion so unrelated content cannot satisfy it.

Q: Should ChatGPT create page objects automatically?

No. Page objects are design abstractions, not a default output format. I introduce them when repeated, stable behavior justifies an API and verify fixture lifecycle, naming, and parallel safety. A small direct test is often clearer.

Q: How do you protect data when using ChatGPT for automation work?

I follow the organization's approved tool and data policy, provide only the minimum context, and replace credentials, customer records, internal URLs, and proprietary logs with synthetic values. Secrets remain in environment or CI stores, never in prompts or generated files.

Common Mistakes

• Giving vague acceptance criteria: The model fills gaps with guesses. Provide observable behavior and mark unknowns.
• Pasting the whole repository: Supply focused context and protect confidential data.
• Accepting invented locators or endpoints: Verify every application-specific identifier.
• Using generated sleeps to fix timeouts: Diagnose the real synchronization or product issue.
• Checking actions without outcomes: Add assertions that prove the requirement.
• Overusing first, last, and nth: Scope by stable meaning unless position is the requirement.
• Generating abstractions too early: Extract fixtures and page objects after stable repetition appears.
• Skipping normal review because code compiles: Run, inspect traces, and review risk like any contribution.
• Measuring generated line count: Measure trusted coverage, stability, review effort, and escaped defects.
• Sending sensitive context: Use approved tooling and minimal synthetic examples.

Conclusion

Using ChatGPT to write Playwright tests can shorten the path from a clear requirement to a useful first draft. The gain comes from precise context, explicit test conventions, and a tight evidence loop, not from accepting code at face value.

Start with one scenario, use the prompt template, run the generated test against the real application, and review every locator and assertion. Keep the model focused on drafting and diagnosis while the SDET owns truth, safety, architecture, and the release decision.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Using Copilot to write Selenium tests (2026)
• Generating Playwright tests from a user story (2026)
• How to Run tests in headed mode in Playwright (2026)
• How to Scroll to an element in Playwright (2026)
• How to Skip and group tests in Playwright (2026)
• AI code review for Playwright tests (2026)