Вы закончили очередное изменение в Next.js. Главная открывается, кнопки на месте, ошибок сборки нет. После публикации выясняется, что одна ссылка ведёт не туда, а нужная страница показывает ошибку. Проверять весь сайт вручную после каждого изменения неудобно. Playwright позволяет поручить браузеру повторяемый сценарий. Он откроет страницу, нажмёт ссылку и проверит результат.
Начнём с одного теста для небольшого приложения Next.js.
Чем Playwright отличается от обычного теста функции
Допустим, в приложении есть функция, которая извлекает номер страницы из URL. Её можно проверить с помощью Vitest, передав несколько значений и сравнив результаты. Пример есть в статье «Как проверить логику приложения с помощью Vitest». Но Vitest не покажет, что происходит, когда посетитель открывает сайт, нажимает ссылку и переходит на другую страницу.
Playwright работает с настоящим браузером. Он может открыть URL, найти элемент на странице, выполнить действие и проверить, что интерфейс изменился ожидаемым образом. Это называется end-to-end тестированием или E2E. Мы проверяем не одну функцию, а пользовательский сценарий.
Устанавливаем Playwright
В проекте Next.js запустите установку из корня приложения.
npm init playwright@latest
Установщик предложит создать каталог с тестами, добавить конфигурацию и скачать необходимые браузеры. Для первого знакомства достаточно Chromium.
После установки появится файл playwright.config.ts и каталог для тестов. В конфигурации зададим локальный адрес приложения.
import { defineConfig, devices } from "@playwright/test";
export default defineConfig({
testDir: "./tests",
use: {
baseURL: "http://127.0.0.1:3000",
...devices["Desktop Chrome"],
},
webServer: {
command: "npm run start",
url: "http://127.0.0.1:3000",
reuseExistingServer: !process.env.CI,
},
});
Здесь Playwright будет использовать Chromium и запускать Next.js на локальном адресе. Команда npm run start требует предварительно собранного приложения.
Сначала выполним сборку.
npm run build
Затем Playwright сможет поднять сервер перед проверкой.
Пишем первый браузерный тест
Предположим, у приложения есть главная страница, ссылка «О проекте» и маршрут /about. Проверим, что пользователь действительно может перейти на эту страницу.
Создадим tests/navigation.spec.ts.
import { test, expect } from "@playwright/test";
test("переход со страницы на страницу", async ({ page }) => {
await page.goto("/");
await page
.getByRole("link", { name: "О проекте" })
.click();
await expect(page).toHaveURL(/\/about\/?$/);
await expect(
page.getByRole("heading", { name: "О проекте" })
).toBeVisible();
});
Тест сначала открывает главную страницу. Затем находит ссылку по её доступному названию, нажимает её и проверяет новый URL. Последняя строка убеждается, что на открывшейся странице есть нужный заголовок. Это пример для сайта с указанными маршрутом и ссылкой. В своём приложении замените названия на существующие элементы.
Такой тест проверяет сразу несколько частей. Работает ли сервер, доступна ли страница, находится ли ссылка и открывается ли нужный раздел.
Запускаем проверку
После production-сборки выполните команду.
npx playwright test
Playwright запустит браузер, пройдёт сценарий и выведет результат в терминал. Если ссылка ведёт на неправильный адрес или заголовок отсутствует, тест завершится ошибкой.
Для просмотра выполнения с открытым браузером можно использовать режим --headed.
npx playwright test --headed
Это помогает увидеть, на каком действии возникла проблема. При этом постоянная работа с открытым браузером не требуется. Обычные автоматические проверки запускаются без него на экране.
Что проверять в приложении в первую очередь
Не нужно сразу писать десятки тестов. Начните с маршрутов, поломка которых заметна пользователю. Для каталога событий подойдут такие сценарии. Открыть главную, перейти к поиску, выбрать категорию, открыть карточку события. Для личного кабинета можно проверить, что посетитель без авторизации не получает доступ к закрытому разделу.
Каждый сценарий лучше делать коротким. Тогда по результату теста видно, какое действие перестало работать.
Отдельно стоит учитывать внешние сервисы. Если приложение зависит от API, который иногда недоступен, тест может падать по причине, не связанной с изменениями вашего кода. Для стабильных проверок используют контролируемые тестовые данные или заранее определённое поведение при ошибке внешнего сервиса.
Почему сайт стоит проверять после сборки
Во время разработки Next.js работает в особом режиме. Некоторые ошибки проявляются только после build, когда приложение подготавливается к запуску. Поэтому браузерную проверку удобно выполнять после production-сборки. Это позволяет заметить проблемы маршрутов, ссылок и отображения до публикации.
Playwright также можно запускать автоматически в CI. Например, после изменений в GitHub. Тогда проверка будет выполняться по одному сценарию без ручных переходов по страницам.
Официальная инструкция Next.js по Playwright содержит варианты настройки и запуска проверок в CI.
От одного перехода к проверке приложения
По мере развития проекта пользовательские сценарии становятся длиннее. Поиск, фильтры, карточки, авторизация и избранное начинают зависеть друг от друга. Проверка отдельной функции уже не отвечает на вопрос, проходит ли человек весь путь через интерфейс.
В EventMap такие сценарии возникают при поиске событий, переходах между страницами и работе с избранным.
Курс «Next.js III: SEO, i18n 2026» объединяет разработку приложения, внешние данные, тесты Vitest и Playwright, CI и деплой на Vercel.
Первый браузерный тест может состоять из одного перехода. По мере роста приложения к нему добавляются сценарии, от которых зависит работа основных пользовательских функций.