How Can GitHub Copilot Write Complete Playwright Tests?

Write a Playwright login test.

test('login', async ({ page }) => {
  await page.goto('/login');
  await page.locator('#email').fill('user@example.com');
  await page.locator('#password').fill('Password123');
  await page.locator('#login').click();
});

Business requirement
        ↓
Test scenarios
        ↓
Page Object or Component Object
        ↓
Fixture initialization
        ↓
Test data
        ↓
Test implementation
        ↓
Assertions
        ↓
Cleanup
        ↓
Execution commands
        ↓
Code review

pages/LoginPage.ts
fixtures/pages.fixture.ts
data/factories/userFactory.ts
tests/ui/login.spec.ts
.github/copilot-instructions.md

playwright-framework/
│
├── tests/
│   ├── ui/
│   ├── api/
│   └── end-to-end/
│
├── pages/
│   ├── BasePage.ts
│   ├── LoginPage.ts
│   └── DashboardPage.ts
│
├── components/
│   ├── HeaderComponent.ts
│   └── ToastComponent.ts
│
├── fixtures/
│   ├── pages.fixture.ts
│   └── testData.fixture.ts
│
├── data/
│   └── factories/
│       └── userFactory.ts
│
├── api/
│   └── services/
│       └── UserApiService.ts
│
├── playwright.config.ts
├── package.json
├── tsconfig.json
└── .github/
    └── copilot-instructions.md

.github/copilot-instructions.md

# Playwright Automation Framework Instructions

This repository contains an enterprise Playwright framework
written in TypeScript.

## Architecture

- UI tests belong in tests/ui/.
- API tests belong in tests/api/.
- Complete pages belong in pages/.
- Reusable UI sections belong in components/.
- Shared setup belongs in fixtures/.
- API operations belong in api/services/.
- Test-data factories belong in data/factories/.
- Generic actions belong in actions/.
- Assertions belong in tests or dedicated assertion classes.

## Locator standards

Use locator strategies in this order:

1. getByRole()
2. getByLabel()
3. getByPlaceholder()
4. getByTestId()
5. Scoped CSS only when necessary

Do not use:

- Absolute XPath
- Auto-generated IDs
- Long CSS chains
- nth() when a unique locator is available

## Synchronization standards

- Use Playwright auto-waiting.
- Use web-first assertions.
- Never use page.waitForTimeout().
- Do not add arbitrary sleep methods.
- Do not use force: true unless the reason is documented.

## Page Object standards

- Page Objects represent complete pages.
- Component Objects represent reusable UI sections.
- Expose business-focused methods.
- Keep assertions outside Page Objects.
- Reuse BasePage methods where available.
- Do not duplicate locators.

## Test standards

- Every test must be independent.
- Every test must be parallel-safe.
- Do not depend on test execution order.
- Create mutable data through factories or APIs.
- Add cleanup for API-created records.
- Use descriptive test names.
- Add tags when appropriate.

## Security

- Never hardcode credentials.
- Never commit authentication-state files.
- Use environment variables for secrets.
- Do not log passwords, tokens, or personal data.

## Validation

Before completing a task:

1. Run TypeScript type checking.
2. Run linting.
3. Run the affected Playwright test.
4. Report any command that fails.
5. Do not modify unrelated files.

A registered customer with valid credentials can log in.

After successful login:

- The customer is redirected to /dashboard.
- The Dashboard heading is visible.
- The authenticated user's name appears in the header.

When an invalid password is entered:

- The user remains on /login.
- An "Invalid email or password" message appears.
- No authenticated session should be created.

Inspect these files before generating code:

- playwright.config.ts
- fixtures/test.fixture.ts
- pages/BasePage.ts
- pages/DashboardPage.ts
- data/factories/userFactory.ts
- tests/ui/registration.spec.ts
- package.json

Use the patterns already established in these files.
Do not create a second fixture system or duplicate utilities.

Implement the Playwright login tests for this repository.

Business requirements:

1. A registered customer with valid credentials can log in.
2. After login, the browser must navigate to /dashboard.
3. The Dashboard heading must be visible.
4. The authenticated user's full name must appear in the header.
5. An invalid password must keep the user on /login.
6. The message "Invalid email or password" must appear.

Inspect these files first:

- playwright.config.ts
- fixtures/test.fixture.ts
- pages/BasePage.ts
- pages/DashboardPage.ts
- data/factories/userFactory.ts
- api/services/UserApiService.ts
- tests/ui/registration.spec.ts
- package.json

Implementation requirements:

- Follow .github/copilot-instructions.md.
- Create or update pages/LoginPage.ts.
- Use getByLabel() for email and password.
- Use getByRole() for the Login button and headings.
- Add business methods named open() and login().
- Keep assertions in the test file.
- Create the registered customer through UserApiService.
- Provide the created customer through a test fixture.
- Delete the customer during fixture teardown.
- Store no credentials in the repository.
- Create tests/ui/login.spec.ts.
- Add one positive and one negative test.
- Make both tests independent and parallel-safe.
- Use web-first assertions.
- Do not use waitForTimeout(), XPath, force clicks,
  shared mutable users, or test-order dependencies.

Validation:

- Run npm run typecheck.
- Run npm run lint.
- Run npx playwright test tests/ui/login.spec.ts.
- Fix errors caused by your changes.
- Summarize the files changed and test results.

Before editing files, provide an implementation plan.

List:

- Existing files you will reuse
- Files you will create or modify
- Fixture changes
- Test-data lifecycle
- Positive and negative scenarios
- Validation commands
- Any missing information or assumptions

Do not write code yet.

1. Inspect the existing fixture structure.
2. Add LoginPage using the existing BasePage.
3. Extend the fixture with a registeredCustomer dependency.
4. Create users through UserApiService.
5. Delete created users after each test.
6. Add valid-login test.
7. Add invalid-password test.
8. Run type checking, linting, and the new test file.

import { Locator, Page } from '@playwright/test';
import { BasePage } from './BasePage';

export class LoginPage extends BasePage {
  readonly emailInput: Locator;
  readonly passwordInput: Locator;
  readonly loginButton: Locator;
  readonly errorMessage: Locator;

  constructor(page: Page) {
    super(page);

    this.emailInput = page.getByLabel('Email');
    this.passwordInput = page.getByLabel('Password');
    this.loginButton = page.getByRole('button', { name: 'Log in' });
    this.errorMessage = page.getByRole('alert');
  }

  async open(): Promise<void> {
    await this.navigate('/login');
  }

  async login(email: string, password: string): Promise<void> {
    await this.emailInput.fill(email);
    await this.passwordInput.fill(password);
    await this.loginButton.click();
  }
}

import { test as base } from '@playwright/test';
import { createUserData } from '../data/factories/userFactory';
import { UserApiService } from '../api/services/UserApiService';
import { LoginPage } from '../pages/LoginPage';
import { DashboardPage } from '../pages/DashboardPage';

interface RegisteredCustomer {
  id: string;
  firstName: string;
  lastName: string;
  email: string;
  password: string;
}

type FrameworkFixtures = {
  loginPage: LoginPage;
  dashboardPage: DashboardPage;
  registeredCustomer: RegisteredCustomer;

};

export const test = base.extend<FrameworkFixtures>({
  loginPage: async ({ page }, use) => {
    await use(new LoginPage(page));
  },

  dashboardPage: async ({ page }, use) => {
    await use(new DashboardPage(page));
  },

  registeredCustomer: async ({ request }, use) => {
    const userApi = new UserApiService(request);
    const userData = createUserData({ role: 'customer' });
    const createdUser = await userApi.createUser(userData);

    try {
      await use({
        id: createdUser.id,
        firstName: userData.firstName,
        lastName: userData.lastName,
        email: userData.email,
        password: userData.password,
      });
    } finally {
      await userApi.deleteUser(createdUser.id);
    }
  },
});

export { expect } from '@playwright/test';

import { test, expect } from '../../fixtures/test.fixture';

test.describe('Customer login', () => {
  test(
    'registered customer can log in',
    { tag: ['@smoke', '@authentication'] },
    async ({ loginPage, dashboardPage, registeredCustomer, page }) => {
      await loginPage.open();

      await loginPage.login(
        registeredCustomer.email,
        registeredCustomer.password,
      );

      await expect(page).toHaveURL(/\/dashboard$/);
      await expect(dashboardPage.heading).toBeVisible();

      await expect(dashboardPage.userMenu).toContainText(
        `${registeredCustomer.firstName} ${registeredCustomer.lastName}`,
      );
    },
  );

  test(
    'customer cannot log in with an invalid password',
    { tag: ['@negative', '@authentication'] },
    async ({ loginPage, registeredCustomer, page }) => {
      await loginPage.open();

      await loginPage.login(
        registeredCustomer.email,
        'IncorrectPassword123!',
      );

      await expect(page).toHaveURL(/\/login$/);

      await expect(loginPage.errorMessage).toHaveText(
        'Invalid email or password',
      );
    },
  );
});

Run the validation commands now:

1. npm run typecheck
2. npm run lint
3. npx playwright test tests/ui/login.spec.ts

For every failure:

- Explain the root cause.
- Fix only failures caused by the new implementation.
- Do not weaken assertions.
- Do not add waitForTimeout().
- Do not add force: true.
- Run the failed command again.

TypeScript error
    ↓
Copilot corrects fixture typing
    ↓
Lint error
    ↓
Copilot applies formatting
    ↓
Locator failure
    ↓
Copilot inspects the accessible name
    ↓
Page Object locator is corrected
    ↓
Tests pass

Review the Playwright implementation you just created.

Check specifically for:

- Incorrect business assumptions
- Weak assertions
- Fragile locators
- Missing teardown
- Hardcoded values
- Shared mutable test data
- Parallel execution risks
- Duplicated framework code
- Page Object responsibilities
- Fixture scope
- Security issues
- Unnecessary abstraction

Do not modify files yet.

Return findings grouped by:

- Critical
- High
- Medium
- Low

/tests

/tests using Playwright Test and the repository fixture system.
Include positive and negative authentication scenarios.
Use existing Page Objects and test-data factories.

Create a complete Playwright TypeScript test implementation
for the supplied business requirement.

Before making changes:

1. Read .github/copilot-instructions.md.
2. Inspect playwright.config.ts.
3. Inspect the existing fixture system.
4. Find related Page and Component Objects.
5. Find a similar existing test.
6. Identify how test data is created and cleaned.

Implementation rules:

- Follow the existing repository architecture.
- Prefer semantic Playwright locators.
- Use web-first assertions.
- Keep assertions in test files.
- Use Page Objects for complete pages.
- Use Component Objects for reusable UI sections.
- Create mutable test data through APIs or factories.
- Add teardown for created data.
- Make every test independent and parallel-safe.
- Do not use fixed waits, absolute XPath, or default force clicks.
- Do not hardcode secrets or environment URLs.
- Do not duplicate existing utilities.

Required output:

- Page or Component Object changes
- Fixture changes
- Test-data changes
- Positive scenario
- Negative scenario
- Validation commands
- Summary of assumptions

Business requirement:

${input}

Implement the checkout-discount Playwright tests described in
issue #145.

Work autonomously inside this repository, but follow these rules:

- Read the repository instructions first.
- Inspect related checkout tests and Page Objects.
- Create a plan before editing.
- Do not modify application source code.
- Do not weaken existing assertions.
- Do not introduce fixed waits.
- Ask before changing shared fixtures.
- Run type checking, linting, and the affected tests.
- Stop and report if the business expectation is ambiguous.

Title:
Add Playwright tests for expired subscriptions

Requirements:

- Create an expired subscription through the API.
- Log in as the subscription owner.
- Open the Subscription page.
- Verify the Expired status.
- Verify premium features are unavailable.
- Verify the renewal button is visible.
- Delete the test subscription after execution.
- Add @subscription and @regression tags.
- Follow repository Copilot instructions.

Copilot reads requirement
        ↓
Browser tool explores application
        ↓
Copilot identifies accessible elements
        ↓
Copilot drafts test plan
        ↓
Engineer reviews plan
        ↓
Copilot generates framework code

Use the supplied accessible HTML to create reliable Playwright
locators.

Do not use CSS IDs unless there is no better semantic locator.

Return:

- The Page Object locators
- The login business method
- Positive and negative tests

page.getByLabel('Email');
page.getByLabel('Password');
page.getByRole('button', { name: 'Log in' });
page.getByRole('alert');

Use tests/ui/registration.spec.ts as the structural pattern.

Follow its:

- Imports
- Fixture usage
- Tags
- test.describe structure
- Naming convention
- Assertion style
- Cleanup strategy

Do not copy its business-specific locators or test data.

Create a test matrix for customer login.

Include:

- Scenario
- Preconditions
- Input data
- Expected result
- Test type
- Priority
- Suitable automation layer
- Whether cleanup is required

Do not write Playwright code yet.

Scenario                      Layer     Priority
----------------------------  --------  --------
Valid customer login          UI        Critical
Invalid password              UI/API    High
Unknown email                 UI/API    High
Empty email                   UI        Medium
Empty password                UI        Medium
Locked account                UI/API    High
Expired password              UI        High
Session created after login   UI/API    Critical

The purpose of this test is to verify login, not registration.

Create the customer through UserApiService before the test.
Do not register the customer through the UI.

Delete the customer in fixture teardown.

email: 'copilot-test@example.com'

All mutable test records must be unique.

Use the existing factory and randomUUID().
Do not use a fixed email, order number, product name, or username.

The generated record must be traceable to automation and safe
for parallel workers.

import { randomUUID } from 'node:crypto';

export function createUserData() {
  const id = randomUUID();

  return {
    firstName: 'Automation',
    lastName: `User-${id.slice(0, 8)}`,
    email: `playwright-${id}@example.test`,
    password: 'TemporaryPassword123!',
  };
}

await page.waitForTimeout(3000);
await loginButton.click();

Use Playwright's built-in auto-waiting.

Do not generate:

- waitForTimeout()
- sleep()
- setTimeout-based waits
- repeated click loops
- force: true as a default

Use web-first assertions when an expected state must be verified.

await loginPage.login(email, password);

Every scenario must contain assertions tied directly to the
business requirement.

Do not validate only that an element exists.

For successful login, verify:

- Final URL
- Dashboard heading
- Authenticated user's name

For failed login, verify:

- Login URL remains active
- Exact error message
- Dashboard is not displayed

await expect(page).toHaveURL(/\/dashboard$/);

await expect(dashboardPage.heading).toHaveText('Dashboard');

await expect(dashboardPage.userMenu).toContainText(
  registeredCustomer.firstName,
);

await expect(message).toContainText('Invalid');

await expect(message).toHaveText('Invalid email or password');

If a test fails, investigate the application behavior and locator.

Do not weaken an assertion merely to make the test pass.
Do not replace exact business expectations with broad text
matches without approval.

page.getByTestId('login-submit');

await expect(page).toHaveURL('/home');

User story or requirement
          ↓
Copilot creates test matrix
          ↓
Engineer selects scenarios
          ↓
Copilot inspects repository
          ↓
Copilot creates implementation plan
          ↓
Engineer reviews plan
          ↓
Copilot updates Page Objects
          ↓
Copilot updates fixtures and data
          ↓
Copilot creates Playwright tests
          ↓
Copilot runs type checking and linting
          ↓
Copilot runs affected tests
          ↓
Copilot fixes implementation errors
          ↓
Copilot performs self-review
          ↓
Human reviews code and business behavior
          ↓
Pull request enters CI/CD

Create a complete Playwright TypeScript implementation for the
following business requirement:

[PASTE REQUIREMENT]

Before editing:

- Read .github/copilot-instructions.md.
- Inspect playwright.config.ts.
- Inspect package.json.
- Inspect the existing fixture system.
- Find related Page Objects and Component Objects.
- Find one similar existing test.
- Identify the test-data creation and cleanup strategy.
- Create an implementation plan.

Implementation requirements:

- Follow the existing architecture.
- Reuse existing framework utilities.
- Use semantic Playwright locators.
- Keep assertions in test files.
- Use Page Objects for complete pages.
- Use Component Objects for reusable sections.
- Create mutable data through factories or APIs.
- Add cleanup for created data.
- Make all tests independent and parallel-safe.
- Use web-first assertions.
- Add meaningful positive and negative coverage.
- Do not use waitForTimeout(), absolute XPath, fixed accounts,
  default force clicks, hardcoded URLs, or hardcoded secrets.
- Do not weaken business assertions to make tests pass.
- Do not modify unrelated files.

Validation:

- Run TypeScript type checking.
- Run linting.
- Run the affected Playwright tests.
- Fix errors caused by the implementation.
- Report remaining failures honestly.

Final response:

- Summarize files created or changed.
- Summarize scenarios covered.
- Report validation results.
- List assumptions and unresolved risks.