Site icon QATechTools

GitHub Copilot for QA: Generate Playwright Tests

bajpaiprashant
GitHub Copilot for QA: Generate Playwright Tests featured image

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:

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.

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:

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

Best practices for a safer workflow

Screenshot checklist

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


Exit mobile version