К основному содержанию
правило официальный · GitHub

playwright-typescript — правило для GitHub Copilot: тесты Playwright

Правило задаёт Copilot стиль написания тестов Playwright: ролевые локаторы, автоожидание, единая структура файлов. Пригодится, если тесты пишет агент, а не человек.

Установить в GitHub Copilot · Вручную: положить файлы Все способы и платформы ↓
.github/instructions/playwright-typescript.instructions.md
Открыть на GitHub

Что делает playwright-typescript

Правило описывает, как генерировать тесты на Playwright. Локаторы Copilot берёт ролевые — getByRole, getByLabel, getByText — и группирует шаги через test.step(). Утверждения должны быть web-first и начинаться с await, например await expect(locator).toHaveText(). Ждать вручную не нужно: правило просит опираться на встроенное автоожидание Playwright и не ставить фиксированные паузы.

Структура тоже задана. Файл начинается с import { test, expect } from '@playwright/test';, связанные тесты собираются в test.describe(), общая подготовка уходит в beforeEach. Лежат тесты в каталоге tests/, имя — <feature-or-page>.spec.ts, по одному файлу на крупную фичу или страницу. Заголовки по схеме «Feature - Specific action or scenario».

Внутри есть пример с поиском фильма и проверкой дерева доступности через toMatchAriaSnapshot. Прогон описан так: сначала npx playwright test --project=chromium, потом разбор падений и правка локаторов. Учтите: правило применяется ко всем файлам (applyTo: '**'), поэтому его указания попадут и в код, который к тестам отношения не имеет. Для GitHub Copilot файл кладут в .github/instructions/playwright-typescript.instructions.md.

Какие задачи решает

  • писать тесты Playwright в одном стиле во всей команде
  • заменить хрупкие CSS-селекторы на ролевые локаторы
  • убрать из тестов фиксированные паузы и ручные ожидания
  • разложить тесты по файлам и блокам describe без разнобоя
  • проверять дерево доступности компонента, а не отдельные узлы

Примеры запросов агенту

  • сгенерируй тест Playwright для страницы поиска по этому правилу
  • перепиши этот тест на ролевые локаторы и test.step()
  • добавь проверку через toMatchAriaSnapshot для блока результатов

Как установить playwright-typescript

Вручную: положить файлы

.github/instructions/playwright-typescript.instructions.md

Поле applyTo задаёт, к каким файлам применять

По шагам, с командами для каждой платформы: AGENTS.md и CLAUDE.md: что это, кто читает и какой выбрать

Вопросы о playwright-typescript

Как установить playwright-typescript в GitHub Copilot?

Создайте файл .github/instructions/playwright-typescript.instructions.md в репозитории и вставьте в него содержимое правила. Copilot подхватит его при генерации кода.

Что делает playwright-typescript?

Задаёт Copilot инструкции по написанию тестов Playwright: какие локаторы использовать, как строить утверждения, как называть и раскладывать файлы.

На что правило влияет кроме тестов?

В нём стоит applyTo: '**', то есть область — весь проект. Указания про локаторы и утверждения будут действовать и в файлах, не связанных с тестами.

Исходный текст

playwright-typescript.instructions.md · MIT
---
description: 'Playwright test generation instructions'
applyTo: '**'
---

## Test Writing Guidelines

### Code Quality Standards
- **Locators**: Prioritize user-facing, role-based locators (`getByRole`, `getByLabel`, `getByText`, etc.) for resilience and accessibility. Use `test.step()` to group interactions and improve test readability and reporting.
- **Assertions**: Use auto-retrying web-first assertions. These assertions start with the `await` keyword (e.g., `await expect(locator).toHaveText()`). Avoid `expect(locator).toBeVisible()` unless specifically testing for visibility changes.
- **Timeouts**: Rely on Playwright's built-in auto-waiting mechanisms. Avoid hard-coded waits or increased default timeouts.
- **Clarity**: Use descriptive test and step titles that clearly state the intent. Add comments only to explain complex logic or non-obvious interactions.


### Test Structure
- **Imports**: Start with `import { test, expect } from '@playwright/test';`.
- **Organization**: Group related tests for a feature under a `test.describe()` block.
- **Hooks**: Use `beforeEach` for setup actions common to all tests in a `describe` block (e.g., navigating to a page).
- **Titles**: Follow a clear naming convention, such as `Feature - Specific action or scenario`.


### File Organization
- **Location**: Store all test files in the `tests/` directory.
- **Naming**: Use the convention `<feature-or-page>.spec.ts` (e.g., `login.spec.ts`, `search.spec.ts`).
- **Scope**: Aim for one test file per major application feature or page.

### Assertion Best Practices
- **UI Structure**: Use `toMatchAriaSnapshot` to verify the accessibility tree structure of a component. This provides a comprehensive and accessible snapshot.
- **Element Counts**: Use `toHaveCount` to assert the number of elements found by a locator.
- **Text Content**: Use `toHaveText` for exact text matches and `toContainText` for partial matches.
- **Navigation**: Use `toHaveURL` to verify the page URL after an action.


## Example Test Structure

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

test.describe('Movie Search Feature', () => {
  test.beforeEach(async ({ page }) => {
    // Navigate to the application before each test
    await page.goto('https://debs-obrien.github.io/playwright-movies-app');
  });

  test('Search for a movie by title', async ({ page }) => {
    await test.step('Activate and perform search', async () => {
      await page.getByRole('search').click();
      const searchInput = page.getByRole('textbox', { name: 'Search Input' });
      await searchInput.fill('Garfield');
      await searchInput.press('Enter');
    });

    await test.step('Verify search results', async () => {
      // Verify the accessibility tree of the search results
      await expect(page.getByRole('main')).toMatchAriaSnapshot(`
        - main:
          - heading "Garfield" [level=1]
          - heading "search results" [level=2]
          - list "movies":
            - listitem "movie":
              - link "poster of The Garfield Movie The Garfield Movie rating":
                - /url: /playwright-movies-app/movie?id=tt5779228&page=1
                - img "poster of The Garfield Movie"
                - heading "The Garfield Movie" [level=2]
      `);
    });
  });
});
```

## Test Execution Strategy

1. **Initial Run**: Execute tests with `npx playwright test --project=chromium`
2. **Debug Failures**: Analyze test failures and identify root causes
3. **Iterate**: Refine locators, assertions, or test logic as needed
4. **Validate**: Ensure tests pass consistently and cover the intended functionality
5. **Report**: Provide feedback on test results and any issues discovered

## Quality Checklist

Before finalizing tests, ensure:
- [ ] All locators are accessible and specific and avoid strict mode violations
- [ ] Tests are grouped logically and follow a clear structure
- [ ] Assertions are meaningful and reflect user expectations
- [ ] Tests follow consistent naming conventions
- [ ] Code is properly formatted and commented

© github · MIT · github/awesome-copilot

Похожие правила IDE

Всё по теме «Тесты и QA» →

Из того же набора732

Весь набор →
powershell Правило для GitHub Copilot, которое заставляет его писать идиоматичные скрипты PowerShell по гайдлайнам Microsoft. Пригодится, если в проекте есть .ps1 и .psm1. ★ 40 418звёзд репо power-platform-connector Правило для GitHub Copilot, которое подсказывает, как писать JSON-схемы кастомных коннекторов Power Platform: Swagger 2.0, apiProperties и settings. ★ 40 418звёзд репо power-bi-devops-alm-best-practices Правило для GitHub Copilot: подсказывает агенту, как вести Power BI-проект в Git, собирать CI/CD и раскатывать отчёты по средам. ★ 40 418звёзд репо power-bi-custom-visuals-development Правило для GitHub Copilot, которое подсказывает агенту, как писать кастомные визуалы Power BI на React, D3.js и TypeScript. ★ 40 418звёзд репо php-symfony Правило задаёт Copilot стиль разработки на Symfony: структура проекта, DI, Doctrine, Twig и тесты. Пригодится, если не хочется объяснять агенту конвенции в каждом чате. ★ 40 418звёзд репо pcf-tooling Правило подсказывает Copilot, что для сборки, отладки и деплоя код-компонентов нужен Microsoft Power Platform CLI. ★ 40 418звёзд репо pcf-manifest-schema Правило подсказывает Copilot структуру ControlManifest.Input.xml: какие элементы и атрибуты бывают и что они делают. Пригодится, когда правишь манифест PCF-компонента. ★ 40 418звёзд репо pcf-events Правило подсказывает Copilot, как объявлять и обрабатывать кастомные события в компонентах Power Apps Component Framework. ★ 40 418звёзд репо

Спонсоры проекта

Компании, которые помогают держать аналитику открытой