Автотесты интерфейса: знакомство с Playwright

Что это

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

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

Для учебного проекта достаточно двух-трёх штук на главные сценарии.

Установка

npm init playwright@latest

Установщик задаст пару вопросов и создаст структуру с примером.

Первый тест

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

test("посетитель видит список заметок", async ({ page }) => {
  await page.goto("http://localhost:3000/notes");
  await expect(page.getByRole("heading", { name: "Заметки" })).toBeVisible();
  await expect(page.getByRole("listitem")).toHaveCount(3);
});

Запуск:

npx playwright test

С открытым браузером, чтобы видеть происходящее:

npx playwright test --headed

Как искать элементы

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

Хорошо — искать так, как ищет человек: по роли и подписи.

page.getByRole("button", { name: "Сохранить" })
page.getByLabel("Почта")
page.getByText("Заметка сохранена")

Плюс такого подхода двойной: тест не ломается при смене оформления и заодно проверяет доступность — если элемент не находится по роли, значит и программа чтения с экрана его не найдёт.

Плохо — искать по служебным именам классов. Поменяли оформление — все тесты упали, хотя ничего не сломалось.

Компромисс — специальные атрибуты для тестов. Ставятся туда, где по-человечески найти нельзя.

Ожидания

Главная причина капризности сквозных тестов — попытки проверять до того, как страница успела обновиться.

Не делайте пауз по времени: они то слишком короткие, то замедляют всё. Правильный подход — ждать состояния:

await expect(page.getByText("Сохранено")).toBeVisible();

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

Заполнение формы

test("можно добавить заметку", async ({ page }) => {
  await page.goto("http://localhost:3000/notes");
  await page.getByLabel("Заголовок").fill("Купить хлеб");
  await page.getByRole("button", { name: "Добавить" }).click();
  await expect(page.getByText("Купить хлеб")).toBeVisible();
});

Это готовый тест главного сценария, который стоит иметь в любом проекте с формами.

Почему такие тесты капризны

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

Что помогает:

Не полагаться на данные с прошлого прогона. Каждый тест готовит себе данные сам.
Не зависеть от порядка. Тесты должны проходить в любой последовательности.
Ждать состояния, а не времени.
Не тестировать интерфейсом то, что можно проверить дешевле. Расчёты — модульными тестами, а не через браузер.

Что даёт в портфолио

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

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