Лучшие практики автоматизации тестирования

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

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

Содержание

1. Философия тестирования
2. Лучшие практики
3. Советы по повышению продуктивности

Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

1. Философия тестирования

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

Автоматизированные тесты должны проверять, что приложение работает так, как ожидает конечный пользователь. Это значит, что тесты должны проверять то, что реально видит и с чем взаимодействует пользователь. Не стоит опираться на технические детали, такие как имена функций, массивы данных или CSS-классы элементов. Если что-то отображается на экране и пользователь с этим взаимодействует, то именно это и нужно проверять в тестах.

Изолируйте тесты по максимуму

Каждый тест должен быть полностью изолирован от других и выполняться независимо, используя свои локальные данные, сессию, файлы куки (cookies) и т.д. Изоляция тестов улучшает воспроизводимость, упрощает отладку и предотвращает цепные сбои тестов.

Чтобы избежать повторений в определенной части теста, вы можете использовать хуки before и after. Добавьте хук before внутри тестового файла, чтобы выполнять определенную часть теста перед каждым тестом, например, переход на определённый URL или вход в приложение. Это сохраняет изоляцию тестов, так как ни один тест не зависит от другого. Однако небольшое дублирование допустимо, особенно если оно делает тесты более понятными и лёгкими для чтения и сопровождения.

Давайте рассмотрим конкретный пример. Чтобы улучшить производительность и упростить тесты, вы можете использовать настройки, позволяющие переиспользовать состояние авторизованного пользователя в тестах. Таким образом, вы входите в систему только один раз, а затем пропускаете шаг входа для всех последующих тестов. Это делает тесты быстрее и проще, так как уменьшается количество повторяющихся действий.

Пример того, как это может выглядеть в Playwright:

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

test.beforeEach(async ({ page }) => {
  // Выполняется перед каждым тестом и выполняет вход на страницу.
  await page.goto('https://github.com/login');
  await page.getByLabel('Username or email address').fill('username');
  await page.getByLabel('Password').fill('password');
  await page.getByRole('button', { name: 'Sign in' }).click();
});

test('первый тест', async ({ page }) => {
  // Страница уже авторизована.
});

test('второй тест', async ({ page }) => {
  // Страница уже авторизована.
});

Вы также можете сохранить эти настройки, чтобы переиспользовать данные для авторизации:

import { test as baseTest } from '@playwright/test';

const test = baseTest.extend({
  storageState: 'state.json', // Сохранение состояния после входа
});

test('тест с повторным использованием состояния', async ({ page }) => {
  await page.goto('https://github.com');
  // Здесь уже используется авторизованное состояние
});

Сохранив данные авторизации (например, в файле state.json), вы можете пропустить процесс входа в систему для последующих тестов. Это не только ускоряет выполнение тестов, но и снижает количество возможных ошибок, связанных с процессом авторизации.

Избегайте тестирования сторонних зависимостей

Тестируйте только то, что вы контролируете. Не пытайтесь тестировать ссылки на внешние сайты или сторонние серверы, которые вам не принадлежат. Это не только отнимает много времени и может замедлить ваши тесты, но и создаёт риски, так как вы не контролируете содержимое страницы, на которую ссылаетесь. Например, это могут быть баннеры с cookies или всплывающие окна, которые приводят к сбою теста.

Вместо этого используйте Network API в Playwright, чтобы симулировать нужный вам ответ:

await page.route('**/api/fetch_data_third_party_dependency', route => route.fulfill({
  status: 200,
  body: testData,
}));
await page.goto('https://example.com');

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

Тестирование с базой данных

Если вы работаете с базой данных, важно обеспечить безопасность данных и их неизменность. Рекомендуется проводить тестирование в промежуточной среде (staging), где данные находятся под вашим контролем. Для визуальных регрессионных тестов убедитесь, что используемые версии операционной системы и браузера идентичны, чтобы минимизировать риски возникновения ошибок.

2. Лучшие практики

Используйте локаторы

Для написания сквозных тестов сначала нужно найти элементы на веб-странице. Это можно сделать с помощью встроенных локаторов Playwright. Локаторы автоматически ожидают, пока элемент станет доступным, и могут повторно пытаться выполнить действие, если это необходимо. Автоматическое ожидание означает, что Playwright проверяет, является ли элемент видимым и активным, прежде чем, например, кликнуть по нему.

Чтобы сделать тесты более надёжными, рекомендуется использовать атрибуты, которые видны пользователю.

// 👍
page.getByRole('button', { name: 'submit' });

Используйте цепочки локаторов и фильтрацию

Локаторы можно связывать в цепочку, чтобы сузить поиск до конкретной части страницы:

const product = page.getByRole('listitem').filter({ hasText: 'Product 2' });

Вы также можете фильтровать локаторы по тексту или другому локатору:

await page
    .getByRole('listitem')
    .filter({ hasText: 'Product 2' })
    .getByRole('button', { name: 'Add to cart' })
    .click();

Используйте атрибуты, видимые для пользователя, а не XPath или CSS-селекторы

Объектная модель документа (DOM) может легко измениться, поэтому, если ваши тесты зависят от её структуры, это может привести к сбоям. Например, если вы выбираете кнопку по её CSS-классам, то любое изменение дизайна, которое изменит класс, может вызвать сбой теста.

// 👎
page.locator('button.buttonIcon.episode-actions-later');

Используйте локаторы, которые устойчивы к изменениям в DOM.

// 👍
page.getByRole('button', { name: 'submit' });

Генерация локаторов

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

Использование “codegen” для генерации локаторов

Для того, чтобы выбрать локатор, выполните команду codegen, указав URL-адрес страницы, с которой вы хотите получить нужный локатор: npx playwright codegen playwright.dev.

Эта команда откроет новое окно браузера и инспектор Playwright. Чтобы выбрать локатор, сначала нажмите кнопку “Record” для остановки записи. По умолчанию, при запуске команды codegen запись начинается автоматически. После остановки записи станет доступной кнопка “Pick Locator”.

Теперь вы можете навести курсор на любой элемент на странице в окне браузера и увидеть выделенный локатор. Кликнув на элемент, вы добавите локатор в инспектор Playwright. Далее вы можете скопировать этот локатор и вставить его в свой тест или продолжить его исследование, редактируя локатор в Playwright Inspector. Например, можно изменить текст и сразу увидеть результаты в окне браузера.

Используйте расширение VS Code для генерации локаторов

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

Используйте веб-ориентированные утверждения (web first assertions)

Утверждения позволяют проверить, совпадает ли ожидаемый результат с фактическим. При использовании веб-ориентированных утверждений Playwright будет автоматически ожидать выполнения условия. Например, при тестировании всплывающего сообщения тест может кликнуть на кнопку, которая вызывает появление сообщения, и затем проверить его наличие. Если сообщение появляется с задержкой, такие утверждения, как toBeVisible(), будут ждать его появления и при необходимости повторять попытку проверки.

await expect(page.getByText('welcome')).toBeVisible();

Не используйте ручные утверждения (manual assertions)

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

В приведённом ниже коде await находится внутри expect, а не перед ним. При использовании таких утверждений, как isVisible(), тест не будет ждать: он сразу проверит наличие локатора и вернёт результат.

// 👎
expect(await page.getByText('welcome').isVisible()).toBe(true);

Вместо этого используйте веб-ориентированные утверждения, такие как toBeVisible().

// 👍
await expect(page.getByText('welcome')).toBeVisible();

Настройка отладки тестов

Локальная отладка

1. Для локальной отладки тестов в Playwright рекомендуется использовать расширение VSCode. Оно позволяет вам запускать тесты в режиме отладки, просто кликнув правой кнопкой мыши на строке рядом с интересующим тестом. Это действие откроет окно браузера и приостановит выполнение в точке останова (breakpoint), что значительно упрощает анализ и исправление ошибок.
   • Также, вы можете отлаживать тест в реальном времени, изменяя или кликая по локаторам в VSCode. Это немедленно отобразится в браузере, где вы увидите выделение соответствующего локатора и другие совпадающие элементы на странице.
2. Ещё один удобный инструмент — инспектор Playwright. Запустите тесты с флагом --debug, используя команду npx playwright test --debug. Это даст возможность пошагово просматривать выполнение теста, анализировать логи действий, а также редактировать локаторы прямо во время выполнения теста. Вы сможете наглядно увидеть, какие локаторы совпадают и сколько их на странице.
   • Для отладки конкретного теста добавьте имя файла и номер строки теста к команде, указав флаг --debug, например: npx playwright test example.spec.ts:9 --debug.

Отладка в системе непрерывной интеграции (CI)

Для устранения ошибок на CI используйте инспектор трассировок Playwright вместо видео и скриншотов. Инспектор трассировок предоставляет полную историю выполнения ваших тестов в виде локального прогрессивного веб-приложения (PWA), которым легко делиться. С его помощью вы можете просматривать временную шкалу тестов, проверять снимки объектной модели документа (DOM) для каждого действия с помощью инструментов разработчика, анализировать сетевые запросы и многое другое.

Трассировки настраиваются в конфигурационном файле Playwright и автоматически запускаются на CI при первой попытке повторного выполнения неудачного теста. Использование трассировок для каждого теста может сильно повлиять на производительность, поэтому лучше ограничить их применение. Однако для локальной разработки вы можете активировать трассировки, используя флаг --trace: npx playwright test --trace on.

После выполнения этой команды отладочные данные будут записаны для каждого теста и будут доступны для просмотра прямо из HTML-отчета: npx playwright show-report. Данные трассировки можно открыть, кликнув на иконку рядом с тестом или открыв отчеты по каждому тесту и прокрутив вниз до соответствующего раздела.

Используйте инструменты Playwright

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

1. Расширение для VS Code. Предоставляет отличные возможности для разработки, упрощая написание, запуск и отладку тестов.
2. Генератор тестов. Может автоматически создавать тесты и подбирать локаторы за вас.
3. Инспектор трассировок. Позволяет просматривать историю выполнения ваших тестов в виде локального прогрессивного веб-приложения (PWA).
4. Режим UI. Позволяет исследовать, запускать и отлаживать тесты с возможностью перемотки во времени и режимом наблюдения. Все файлы тестов загружаются в боковую панель тестирования, где вы можете развернуть каждый файл и блок описания для индивидуального запуска, просмотра, наблюдения и отладки тестов.
5. TypeScript в Playwright. Работает сразу после установки и предоставляет лучшие интеграции с IDE. Ваша IDE покажет вам все доступные функции и выделит ошибки. Опыт работы с TypeScript не требуется, и ваш код не обязательно должен быть на TypeScript: достаточно создать тесты с расширением .ts.

Тестирование в различных браузерах

Playwright упрощает тестирование вашего сайта в разных браузерах, независимо от платформы. Это гарантирует, что ваше приложение будет работать корректно для всех пользователей.

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

Пример конфигурации в файле playwright.config.ts:

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

export default defineConfig({
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },
  ],
});

В этом примере настроены проекты для тестирования в браузерах Chromium, Firefox и WebKit.

Регулярное обновление версии Playwright

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

Для того, чтобы установить последнюю версию, используйте команду: npm install -D @playwright/test@latest. Для проверки текущей версии Playwright выполните команду: npx playwright --version.

Проверяйте примечания к выпуску, чтобы узнать, какая версия является последней и какие изменения были внесены.

Запуск тестов в системе непрерывной интеграции (CI)

Настройте процессы CI/CD и запускайте тесты регулярно. Чем чаще вы запускаете тесты, тем быстрее обнаружите и устраните проблемы. Оптимальным вариантом является запуск тестов при каждом коммите (commit) и запросе на слияние (pull request).

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

Рекомендуется использовать Linux для запуска тестов на CI, так как это более экономично. Разработчики могут использовать любую среду для локального запуска тестов, но для CI лучше выбрать Linux, чтобы снизить затраты и обеспечить стабильность тестирования.

Линтинг (linting) тестов

Линтинг тестов — это процесс автоматической проверки кода тестов на соответствие установленным стандартам и правилам. Он помогает выявлять ошибки на ранних стадиях разработки и улучшает качество кода. Для этого рекомендуется использовать правило ESLint @typescript-eslint/no-floating-promises, которое помогает убедиться, что перед асинхронными вызовами к API Playwright нет пропущенных await.

Использование параллельного выполнения тестов и шардирование

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

Пример настройки параллельного выполнения тестов:

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

test.describe.configure({ mode: 'parallel' });

test('runs in parallel 1', async ({ page }) => { /* ... */ });
test('runs in parallel 2', async ({ page }) => { /* ... */ });

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

Пример команды для запуска тестов с шардированием: npx playwright test --shard=1/3.

В этом примере тесты разделены на три части, и текущая команда выполнит только первую из них.

Примечание редакции: вас также может заинтересовать статья “Лучшие практики автоматизации для комплексного тестирования ПО”.

3. Советы по повышению продуктивности

Используйте “мягкие” утверждения (soft assertions)

Если тест не проходит, Playwright отображает сообщение об ошибке, которое указывает, какая часть теста вызвала сбой. Это сообщение можно увидеть в VS Code, терминале, HTML-отчете или в инспекторе трассировок.

Вы также можете использовать “мягкие” утверждения. Они не приводят к немедленному завершению теста при невыполнении условия. Вместо этого они регистрируют ошибку и продолжают выполнение теста. Это удобно для проверки некритических условий.

Пример их использования:

// Выполните несколько проверок, которые не остановят тест при ошибке...
await expect.soft(page.getByTestId('status')).toHaveText('Success');

// ... и продолжайте тестировать, проверяя другие элементы
await page.getByRole('link', { name: 'next page' }).click();

“Мягкие” утверждения позволяют продолжить выполнение теста и проверку других условий, даже если некоторые утверждения не прошли.

Перевод статьи «Best Practices».