Playwright config — смотрим в деталях

Когда вы стартуете новый Playwright проект и запускаете:

npm init playwright@latest

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

Содержимое файла можно разделить на несколько разделов:

• общая конфигурация
• use
• projects

Общая конфигурация

Свойства, которые можно определить в этом разделе:

• timeout — максимальный лимит времени для каждого теста;
• globalTimeout — максимальный лимит времени для запуска всего тест сьюта. Бесконечный цикл, утечки памяти при запуске CI? Больше нет: выполнение скрипта будет завершено, если превышено заданное время. (Аналог таймаута для выполнения тестов в CI-tool);
• globalSetup определяет файл, который будет выполняться до запуска набора тестов, globalTeardown указывает на файл, который будет выполняться после завершения всех тестов.
  В документации Playwright показано, как эти файлы можно использовать, например, для повторной авторизации при выполнении каждого теста;
• name — название вашего тест-сьюта;
• свойство testDir позволяет задать каталог, который будет сканироваться на наличие файлов с тестами;
• snapshotDir путь к месту, где хранятся снапшоты (используемые для визуальных регрессионных тестов;
• outputDir путь к месту хранения результатов тестирования (логи, видео, скриншоты). По умолчанию сохраняются результаты тестирования, но вы можете изменить это значение так, чтобы сохранялись только упавшие тесты. В разделе projects это значение может быть переопределено для требований каждого проекта.

testDir: './tests',
  timeout: 30 * 1000,
  
  globalTimeout: process.env.CI ? 60 * 60 * 1000: 30 * 60 * 1000,
  globalSetup: './global-setup.js',
  globalTeardown: './global-teardown.js',

• retries в случае неудачи теста Playwright будет пробовать выполнить тест столько раз, сколько указано в свойствах retries. Значение по умолчанию равно 0. В результате тест, который пришлось повторно запустить для получения успешного результата, будет помечен как flaky, а не failed. Это говорит о том, что необходимо его изменить.
• forbidOnly — для запуска одного теста вы можете добавить тег .only (пример кода ниже), что отлично помогает при работе над одним тестом. Но обычно вы не хотите выполнять только один тест в CI-пайплайне. Свойство forbidOnly: true будет выдавать ошибку и завершать тесты с кодом 1

test.only('homepage has Playwright

• workers — это процессы, которые запускаются независимо в отдельных браузерах. Сколько таких процессов будет создано для выполнения набора тестов, зависит от лимита памяти вашей машины. Программа запуска тестов будет использовать их повторно, поэтому несколько тестовых файлов обычно запускаются в одном worker-e один за другим. Но вы можете захотеть ограничить их количество (например, в CI);
• fullyParallel — при установке этого свойства в true тесты будут выполняться параллельно, что отменяет поведение worker-a по умолчанию — выполнение файла за файлом;
• свойство shard позволяет разделить тесты для нескольких машин, скажем, 1/2 и 2/2, чтобы запускать их параллельно для ускорения выполнения тестов. Подробнее о реализации в документации
• testMatch Определяет шаблон, используемый файлами тестов, например: testMatch: "*/?(.)@(spec|test).*" Тесты выполняются в алфавитном порядке имен файлов. Предоставив файл testMatch: test.list.js со списком тестов, вы можете указать свой порядок выполнения.
  Аналогично testMatch вы можете использовать testIgnore — шаблон имени файла, который будет игнорироваться при выполнении теста.
• maxFailures вы также можете указать максимальное количество неудач, после которых тесты завершатся с кодом 1. Это удобно для CI, чтобы не тратить ресурсы впустую, если мы знаем, что пайплайн уже не пройдет.

retries: process.env.CI ? 2 : 0,
  forbidOnly: !!process.env.CI,
  workers: process.env.CI ? 1 : undefined,
  fullyParallel: true,
  testMatch: 'test.list.js',
  maxFailures: process.env.CI ? 10 : undefined,

• grep и grepInvert В ваших тестах используются теги типа @develop, @visual для запуска только определенных тестов? Вы также можете задать его в конфигурации. Лично я предпочитаю передавать его динамически в зависимости от окружения и конкретных тестов, которые нужно запустить.
• reporter принимает одну строку или массив массивов и принимает объект с параметрами репортера. Встроенные репортеры на выбор: dot, github, html, json, junit, line, list, null. Или вы можете создать свой собственный. Поэкспериментируйте со всеми из них и посмотрите, какой вам больше подходит.
• reportSlowTests По умолчанию это число равно 5, и в конце выполнения тест-сьюта вы увидите до 5 самых медленных тестов. Вы можете изменить это число здесь, а также указать, что является порогом времени для медленного теста.
• metadata — это объект, который может быть добавлен в отчет. Это может помочь в отладке тестов, поскольку в метаданные может быть записана информация об операционной системе.

reporter: [
    ['html', { outputFolder: 'test-results' }], 
    ['json', { outputFolder: 'test-results', outputFile: 'report.json' }],
  ],
  metadata: {
    hostFreeMemory: os.freemem()
  },

• Playwright может фактически запустить веб-сервер для вас! И будет ждать, пока служба не ответит кодом состояния 2xx HTTP. Просто укажите все необходимые значения, такие как: команда для запуска, порт или URL, таймаут и т.д.
• expect — этот раздел относится к утверждениям внутри тестов. Это подходящее место для переопределения таймаута по умолчанию (который составляет 5000 миллисекунд); В этой части вы также можете добавить глобальные настройки для визуальных регрессионных тестов, определив методы toHaveScreenshot и toMatchSnapshot, которые будут применяться ко всем вашим визуальным тестам — допустим, вы хотите разрешить maxDiffPixelRatio равным 0.01.

expect: {
     timeout: 6000,
     toHaveScreenshot: {
       animations: 'disabled'
     },
     toMatchSnapshot: {
       maxDiffPixelRatio: 0.01
     },
   },

Раздел Use

Этот раздел содержит свойства, общие между всеми проектами, и значения, определяющие контекст тестов (TestOptions):

• acceptDownloads принимает булево значение и очень полезно для тестирования функциональности загрузки файлов в приложении.
• actionTimeout по умолчанию равно 0. Добавляет значение таймаута для таких действий на странице, как click(), type() и т.д.
• navigationTimeout page.goto() в приложении занимает немного больше времени, позволяя странице загрузиться. Вы можете указать таймаут либо здесь, либо в самом методе.
  Можно определить его здесь, либо указывать его в отдельных действиях (page.click({ timeout: 1000 })).
• baseURL базовый URL тестируемого приложения. Может быть указан напрямую или задаваться переменными окружения (process.env.BASE_URL).
• serviceWorkers Здесь вы можете разрешить (allow) или заблокировать (block) регистрацию service workers. По умолчанию разрешено.
• geolocation Допустим, вы хотите проверить, как выглядит и работает ваше приложение при использовании пользователем из другой части мира, меняется ли локаль и видит ли пользователь свою языковую версию приложения? Здесь вы можете указать желаемую геолокацию.
• locale и timezoneId — тестируете i18n (интернационализацию) или l10n (локализацию)? Свойства locale и geolocation помогут вам автоматизировать эти тесты.
• Когда вы используете геолокацию, не забудьте также дать браузеру разрешение на ее использование, определив его в свойстве permissions. Здесь также можно разрешить уведомления, запись в буфер обмена, чтение из буфера обмена (для копирования/вставки с API буфера обмена) и т.д.
• headless Выполнять тесты в режиме headless или headful браузера; true или false? Обычно true (по умолчанию), так как можно запускать тесты в фоновом режиме, но при работе над тестами и отладке false. Я предпочитаю передавать это значение в команде, а не устанавливать его в конфиге.
• ignoreHTTPSErrors с этим значением, установленным в true, вы можете игнорировать ошибки, связанные с HTTPS в локальной среде.
  Тестируете ответ API и получаете ошибку? Убедитесь, что у вас установлено это значение.
• screenshot , video и trace здесь вы можете указать, хотите ли вы сохранить их в каталоге результатов тестирования после завершения тестов. Доступные опции: on, off, retain-on-failure. Это очень помогает при отладке неудачных тестов, поэтому мы рекомендуем установить это свойство в on.
• Свойство viewport определяет область просмотра браузера. Очень полезно в визуальных регрессионных тестах.
• offline удобный параметр, если вы тестируете Progressive Web Application и хотите проверить, как приложение ведет себя в автономном состоянии или если вы просто хотите проверить, что видит пользователь, когда сеть недоступна.
• storageState вы можете использовать эту опцию, чтобы, скажем, установить cookies для всех ваших тестов. Вы можете просто установить состояние хранилища здесь, а не повторять это во всех тестах.
• hasTouch, isMobile опции по умолчанию имеют значение false. Могут быть перезаписаны в отдельном тесте, что очень полезно для тестов эмуляции на мобильных устройствах.
• Вы можете подключаться к удаленным браузерам и переопределять параметры (браузер, контекст и страницу) с помощью connectOptions — объекта Option, который принимает wsEndpoint и необязательные заголовки в качестве параметров.
• browserName позволяет указать название браузера (по умолчанию chromium) и сборку (chrome-canary).
• если вы тестируете API и вызовы требуют аутентификации, вы можете определить ее в extraHTTPHeaders чтобы APIRequestContext мог ее использовать.
• Настройки прокси также могут быть указаны в конфигурации Playwright, если это требуется для ваших тестов. Эта опция принимает объект с HTTP или SOCKS сервером и именем пользователя и паролем аутентификации.

use: {
    acceptDownloads: true,
    actionTimeout: 0,
    baseURL: 'www.katk.dev',
    colorScheme: 'dark',
    viewport: { width: 1280, height: 720 },
    geolocation: { longitude: 19.944544, latitude: 50.049683 },
    headless: false,
    ignoreHTTPSErrors: true,
    locale: 'en-GB',
    permissions: ['notifications', 'geolocation', 'clipboard-read'],
    screenshot: 'only-on-failure',
    trace: 'retain-on-failure',
    video: 'on-first-retry',
  }

Раздел Projects

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

projects: [
    {
      name: 'project one',
      use: {
        ...devices['Desktop Chrome'],
        baseURL: process.env.POST_ONE_URL || 'www.katk.dev/post-one',
        colorScheme: 'light',
        storageState: 'storage/user1.json'
      },
    },
     {
      name: 'project two',
      use: {
        ...devices['Desktop Chrome'],
        baseURL: process.env.POST_TWO_URL || 'www.katk.dev/post-two',
        colorScheme: 'dark',
        storageState: 'storage/user2.json'
      },
    },
]

Вот и все! Подробную информацию можно найти на официальном сайте Playwright.

Все вышесказанное взято в основном из моего собственного опыта и проектов, над которыми я работал.

Надеюсь, это помогло вам лучше понять конфигурацию Playwright!