Глобальные настройки

Урок: Глобальные настройки и выполнение один раз на весь прогон в Playwright Test

Введение

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

Это похоже на ситуацию, когда перед каждым уроком ты заново настраиваешь проектор, расставляешь стулья и включаешь свет. Хотя логичнее сделать это один раз перед началом занятий, а не перед каждым объяснением темы.

В Playwright есть два важных механизма, которые решают эту проблему:

глобальные настройки — задают общее поведение для всех тестов;
код, который выполняется один раз на весь прогон — подготавливает окружение заранее.

Если правильно их использовать, тесты становятся быстрее, чище и стабильнее.

Что значит «глобальные настройки»

Глобальные настройки — это такие параметры, которые автоматически применяются ко всем тестам без необходимости указывать их в каждом файле.

Часть таких настроек мы уже видели в конфигурации:

export default defineConfig({
  use: {
    baseURL: 'http://localhost:3000',
    headless: true,
  },
});

Здесь важно понять ключевую идею:

мы описываем поведение один раз, а используем везде.

Например, благодаря baseURL:

await page.goto('/');

Playwright сам подставит полный адрес. Тест не знает, какой именно URL используется — он просто следует глобальной настройке.

То же самое касается:

таймаутов;
режима браузера;
скриншотов;
trace;
viewport.

Это и есть глобальная конфигурация: единые правила для всех тестов.

Почему не стоит дублировать настройки в тестах

Посмотрим на два варианта.

Без глобальных настроек:

test('пример', async ({ page }) => {
  await page.goto('http://localhost:3000');
});

С глобальными настройками:

test('пример', async ({ page }) => {
  await page.goto('/');
});

Во втором случае:

тест короче;
меньше шансов ошибиться;
проще изменить адрес (в одном месте — в конфиге).

Теперь представь, что URL поменялся. В первом варианте тебе придется менять его во всех тестах. Во втором — только в конфигурации.

Именно поэтому глобальные настройки — это не просто удобство, а основа масштабируемости тестового проекта.

Когда нужен код «один раз на весь прогон»

Теперь другая ситуация.

Допустим, перед запуском тестов нужно:

создать тестового пользователя;
очистить базу данных;
залогиниться и сохранить состояние;
подготовить тестовые данные.

Если делать это внутри каждого теста — будет:

медленно;
дублирование кода;
больше нестабильности.

Логичнее сделать это один раз перед запуском всех тестов.

Для этого в Playwright есть механизм глобальной инициализации.

Глобальный setup (globalSetup)

Playwright позволяет выполнить специальный файл перед запуском всех тестов. Это называется globalSetup.

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

import { defineConfig } from '@playwright/test';

export default defineConfig({
  globalSetup: './global-setup.ts',
});

Теперь создадим сам файл:

// global-setup.ts
import { chromium } from '@playwright/test';

export default async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();

  await page.goto('http://localhost:3000/login');
  await page.fill('#username', 'test-user');
  await page.fill('#password', 'password');
  await page.click('button[type=submit]');

  // сохраняем состояние
  await page.context().storageState({ path: 'storageState.json' });

  await browser.close();
};

Разберем, что здесь происходит.

Playwright перед запуском тестов выполняет этот файл.
Мы открываем браузер вручную.
Выполняем логин.
Сохраняем состояние (cookies, localStorage).
Закрываем браузер.

Этот код выполняется один раз на весь прогон.

Использование результата глобального setup

Теперь самое интересное — как использовать результат.

Добавим в конфигурацию:

export default defineConfig({
  use: {
    storageState: 'storageState.json',
  },
});

Что это значит?

Каждый тест теперь будет:

автоматически начинаться в уже залогиненном состоянии;
без необходимости повторять логин.

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

test('проверка профиля', async ({ page }) => {
  await page.goto('/profile');
});

Здесь нет логина. Но пользователь уже авторизован.

Это мощный прием:

мы один раз делаем тяжелую операцию, а потом используем результат во всех тестах.

В чем разница между глобальными настройками и setup

Важно не путать два понятия.

Глобальные настройки — это параметры (например: URL, таймауты, браузер)

Глобальный setup — это код (например: логин, создание данных)

Проще запомнить так:

конфигурация описывает «как запускать»;
setup выполняет «что нужно подготовить».

Они работают вместе, но решают разные задачи.

Альтернатива: проекты и подготовка через них

Иногда вместо globalSetup используют проекты.

Например, можно сделать отдельный проект, который подготавливает состояние:

projects: [
  {
    name: 'setup',
    testMatch: /.*\.setup\.ts/,
  },
  {
    name: 'tests',
    dependencies: ['setup'],
  },
];

Это более гибкий способ, особенно в больших проектах. Но на старте проще использовать globalSetup.

Практический смысл

Теперь посмотрим на реальную пользу.

Без глобального setup:

каждый тест логинится;
тесты работают медленно;
больше сетевых запросов;
выше вероятность падений.

С глобальным setup:

логин выполняется один раз;
тесты становятся быстрее;
код тестов чище;
меньше нестабильности.

Глобальные настройки дают единые правила, а глобальный setup — готовое состояние.

Вместе они превращают тестовый проект из набора разрозненных сценариев в системный инструмент.

Итоговое понимание

Главная идея этой темы в том, что в тестах не должно быть лишнего повторения — ни в настройках, ни в подготовке данных.

Глобальные настройки позволяют один раз описать среду выполнения тестов и не дублировать ее в каждом файле.

Глобальный setup позволяет один раз подготовить состояние (например, логин или данные) и использовать его во всех тестах.

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