GitHub Copilot Playwright tests can save time, but only if you treat Copilot as a drafting assistant instead of an autopilot button. GitHub’s own docs say Copilot Chat can help write tests, including end-to-end tests for webpages, and that the /tests command can generate tests for the active file or selected code. The same docs also make the boundary clear: you still need to provide the right context and review the output before using it in production. For QA engineers, that is the useful mindset.

This tutorial shows a practical workflow for turning one user story into a reviewed Playwright test. The goal is not to get a perfect test on the first prompt. The goal is to get a good draft quickly, then improve locators, assertions, and coverage before commit.

When GitHub Copilot fits this QA task

Copilot works best here when you already have a small amount of structure:

  • A user story with acceptance criteria
  • A page or flow that already exists in the application
  • An existing Playwright project with the right test runner configuration
  • A tester who can verify whether the generated assertions actually prove the behavior

If those pieces are missing, Copilot usually fills the gaps with assumptions. That is where weak tests start.

Example user story

Use a narrow story so Copilot has a bounded task:

Story: As a shopper, I want to sign in so I can see my saved orders.

Acceptance criteria:
1. Valid credentials open the account dashboard.
2. Invalid credentials show an error message.
3. The sign-in button stays disabled until email and password are filled.
4. The dashboard heading should be visible after login.

This is enough context for a first draft. If you also have the login page open and the current test file selected, Copilot has a better chance of generating relevant Playwright code.

Step 1: Prepare context before prompting Copilot

GitHub Docs recommend attaching the right context with selections, files, and workspace references. For QA work, that means you should not ask Copilot for a blind test from one sentence alone.

  • Open the existing Playwright spec folder or a nearby test file.
  • Highlight the user story or paste it into the chat.
  • Attach the page object, route file, or component file if the selectors are not obvious.
  • Tell Copilot which framework and language to use.

A good prompt is specific about the flow, the assertions, and the review constraints.

Copy Example: first Copilot prompt

Using Playwright with TypeScript, draft one UI test for this user story.
Use readable locators and avoid brittle nth-child selectors.
Add assertions for button state, error handling, and successful navigation.
If you are unsure about a locator, leave a short TODO comment instead of guessing.

User story:
As a shopper, I want to sign in so I can see my saved orders.

Acceptance criteria:
1. Valid credentials open the account dashboard.
2. Invalid credentials show an error message.
3. The sign-in button stays disabled until email and password are filled.
4. The dashboard heading should be visible after login.

This prompt follows GitHub’s guidance well: it is specific, task-oriented, and explicit about expected behavior.

Step 2: Let Copilot draft the first Playwright test

In many editors, you can use Copilot Chat directly or use /tests on the selected code or file. For an end-to-end flow, Copilot often returns a draft similar to this:

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

test('user can sign in and view dashboard', async ({ page }) => {
  await page.goto('/login');

  const email = page.getByLabel('Email');
  const password = page.getByLabel('Password');
  const signInButton = page.getByRole('button', { name: 'Sign in' });

  await expect(signInButton).toBeDisabled();

  await email.fill('qa.user@example.com');
  await password.fill('wrong-password');
  await expect(signInButton).toBeEnabled();
  await signInButton.click();

  await expect(page.getByText('Invalid email or password')).toBeVisible();

  await password.fill('CorrectPassword123');
  await signInButton.click();

  await expect(page).toHaveURL(/dashboard/);
  await expect(page.getByRole('heading', { name: 'My Orders' })).toBeVisible();
});

This is a useful draft, not a finished test. The next step is the part many teams skip.

Step 3: Review locators and assertions like a QA engineer

GitHub’s best-practices and Copilot Chat docs both stress reviewing generated code. For Playwright tests, review these items first:

  • Locator quality: prefer labels, roles, placeholders, and stable test IDs over CSS chains.
  • Assertion quality: check whether the assertion proves the requirement or only checks that something happened.
  • State transitions: make sure the test verifies both the failing path and the successful path.
  • Test data: confirm the credentials and environment assumptions are realistic for your test environment.

In the sample above, the dashboard assertion may be wrong if the real page heading is Account Dashboard rather than My Orders. Copilot also reused the same test for both invalid and valid login, which can make failure analysis noisier. A QA-minded refactor is to split the scenario into smaller tests or use a shared helper.

Step 4: Add missing edge cases from the acceptance criteria

Copilot often covers the happy path first. Ask for the missing edge behavior explicitly.

Add one more Playwright test for invalid login.
Keep it separate from the successful login test.
Verify the error message and confirm the user remains on the login page.
Use the same locator style as the existing test.

This follow-up prompt is where Copilot becomes useful for daily QA work. You give it a bounded revision request instead of asking it to invent the whole strategy.

Starter snippet after review

test('invalid login shows an error and keeps the user on login', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('qa.user@example.com');
  await page.getByLabel('Password').fill('wrong-password');
  await page.getByRole('button', { name: 'Sign in' }).click();

  await expect(page.getByRole('alert')).toContainText('Invalid email or password');
  await expect(page).toHaveURL(/login/);
});

Notice the improvement: the assertion checks a clearer error surface and confirms the user is still on the login page.

Common mistakes when using GitHub Copilot Playwright tests

  • Accepting guessed selectors without checking the DOM or accessibility tree
  • Keeping one giant test that mixes multiple business behaviors
  • Using only URL assertions and forgetting visible business outcomes
  • Skipping negative paths because the first Copilot answer looks complete
  • Trusting generated credentials, routes, or fixture names that do not exist in the project

Best practices for a safer workflow

  • Start from one story and one flow, not a full regression suite.
  • Tell Copilot what to avoid, such as brittle selectors or invented helpers.
  • Use existing files and project context so the draft matches your repo style.
  • Run the test immediately and inspect failures before polishing the code.
  • Keep human review focused on evidence: locators, assertions, waits, data, and maintainability.

Screenshot checklist

  • Copilot Chat panel showing the user-story prompt
  • The generated Playwright draft in the editor
  • The login page with accessible labels or test IDs visible in dev tools
  • The failing or passing Playwright run in the terminal or test runner
  • The final reviewed test with improved assertions

FAQ

Can GitHub Copilot generate complete Playwright tests from a user story?
It can generate a strong draft, but you should still verify selectors, test data, assertions, and split scenarios when needed.

Should I use the /tests command or a normal prompt?
Use either, but keep the task specific. /tests is useful for the active file or selection, while a normal prompt is better when you want to paste acceptance criteria and extra review instructions.

What should I review first in Copilot-generated UI tests?
Review locator stability, whether the assertions prove the requirement, and whether the flow covers both expected and negative behavior.

Is this workflow useful for manual testers too?
Yes. Even if you do not own the final automation code, Copilot can help turn requirements into draft scenarios that an SDET or automation engineer can refine.

Conclusion

GitHub Copilot Playwright tests are most useful when you give Copilot a narrow story, clear acceptance criteria, and explicit quality rules. GitHub’s official docs support this pattern: provide context, use test-writing workflows, and validate the result before production use. For QA teams, the win is faster drafting without giving up engineering judgment.

References