Структура директорий проекта

Организация структуры директорий является важным аспектом при работе с Playwright, так как правильная настройка проекта позволяет упростить тестирование, повысить читаемость кода и ускорить его поддержку. В этом разделе рассматривается типичная структура директорий для проекта с тестами на Playwright и рекомендации по её организации.

1. Основные директории

node_modules Это стандартная директория для хранения всех зависимостей проекта, установленных с помощью npm или yarn. В проекте на Playwright сюда попадут все библиотеки, включая сам Playwright и его зависимости. Эта директория обычно не включается в систему контроля версий (например, в .gitignore).

tests Основная директория для хранения тестов. В ней обычно создаются подкаталоги для разных типов тестов (например, для функциональных тестов, тестов на производительность или тестов UI). Рекомендуется организовывать файлы тестов по модулям, функциональным областям или страницам, чтобы упростить навигацию и поддержку тестов.

Пример структуры:

tests/
  ├── login/
  │   ├── login.spec.js
  │   └── login.page.js
  ├── dashboard/
  │   ├── dashboard.spec.js
  │   └── dashboard.page.js
  └── userManagement/
      ├── user.spec.js
      └── user.page.js

tests/login В этой директории хранятся тесты, связанные с функциональностью входа в систему. Это могут быть тесты проверки успешного входа, обработки ошибок при вводе неправильных данных и т. д. Помимо тестовых файлов (login.spec.js), здесь может быть отдельный файл с объектом страницы (login.page.js), который инкапсулирует взаимодействие с элементами формы входа.

2. Структура тестов

Тестовые спецификации (specs) Файлы тестов Playwright обычно имеют расширение .spec.js (или .ts, если используется TypeScript). Эти файлы содержат непосредственно тесты, которые могут быть выполнены с помощью команды npx playwright test.

Пример теста:

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

test('проверка входа с корректными данными', async ({ page }) => {
  await page.goto('https://example.com/login');
  await page.fill('#username', 'user');
  await page.fill('#password', 'password');
  await page.click('#login-button');
  await expect(page).toHaveURL('https://example.com/dashboard');
});

Объекты страниц (Page Objects) В Playwright принято использовать паттерн Page Object, который позволяет организовать взаимодействие с элементами страницы в отдельные классы или модули. Это помогает повысить читабельность тестов и облегчить их поддержку. Обычно для каждой страницы сайта создается отдельный файл, в котором инкапсулируются все действия с элементами страницы.

Пример объекта страницы:

class LoginPage {
  constructor(page) {
    this.page = page;
    this.usernameInput = page.locator('#username');
    this.passwordInput = page.locator('#password');
    this.loginButton = page.locator('#login-button');
  }

  async login(username, password) {
    await this.usernameInput.fill(username);
    await this.passwordInput.fill(password);
    await this.loginButton.click();
  }
}

export default LoginPage;

3. Вспомогательные директории

utils Директория для хранения вспомогательных функций и утилит. Здесь могут быть функции для обработки данных, создания отчетов, работы с файлами или выполнения сложных действий, которые не относятся непосредственно к логике тестов.

Пример структуры:

utils/
  ├── data.js
  ├── logger.js
  └── helpers.js

config В этой директории обычно хранятся конфигурационные файлы, включая настройки для Playwright, параметры окружений (например, URLs для разных сред, данные для аутентификации) и глобальные настройки для тестов. Конфигурация может быть организована через playwright.config.js или playwright.config.ts, в зависимости от использования TypeScript.

Пример конфигурации:

// playwright.config.js
module.exports = {
  use: {
    baseURL: 'https://example.com',
    headless: false,
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
  projects: [
    {
      name: 'firefox',
      use: { browserName: 'firefox' },
    },
    {
      name: 'webkit',
      use: { browserName: 'webkit' },
    },
  ],
};

reports Директория для хранения отчетов, например, HTML-отчетов, создаваемых после выполнения тестов, логов и скриншотов. Обычно в этой папке также содержатся видео или снимки экрана, снятые при запуске тестов, которые могут помочь в отладке.

Пример структуры:

reports/
  ├── latest-results/
  │   ├── report.html
  │   ├── screenshot-1.png
  │   └── video-1.mp4
  └── archived/
      └── report-2026-01-01.html

4. Структура для CI/CD

Для удобства интеграции с системами непрерывной интеграции и доставки (CI/CD), проект на Playwright можно организовать с учетом автоматического запуска тестов. В директории проекта часто создается дополнительная папка для конфигурации CI, в которой хранятся настройки для GitHub Actions, GitLab CI, Jenkins или других систем.

Пример конфигурации для GitHub Actions:

.github/
  └── workflows/
      └── playwright.yml

Пример файла playwright.yml:

name: Playwright Tests

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'
      - name: Install dependencies
        run: npm install
      - name: Run Playwright tests
        run: npx playwright test

5. Типичные подходы к организации

Модульная структура При большом проекте или сложной структуре приложения логично разделить тесты по модулям. Например, если приложение состоит из нескольких функциональных частей, то для каждой из них может быть отдельный каталог с тестами.

Тестирование по страницам Другим распространенным подходом является организация тестов по страницам приложения. В этом случае для каждой страницы сайта или компонента создается отдельный каталог с тестами и объектами страниц.

Заключение

Организация структуры директорий в проекте с использованием Playwright напрямую влияет на удобство разработки, тестирования и дальнейшего масштабирования проекта. Важно придерживаться ясной и логичной структуры, которая будет соответствовать потребностям проекта и обеспечит легкость в обслуживании тестов.

Оглавление