Тесты сайта: что такое сквозной тест

Сквозной (e2e) тест — программа, которая в настоящем браузере проходит путь человека по сайту и сверяет результат с ожидаемым.

Зачем машине проверять сайт

Первый тест сайта это вы сами: открыли, нажали, посмотрели. На маленьком сайте и в первый раз этого хватает. Но каждая правка может сломать что-то далёкое: переименовали класс в подвале, и форма наверху перестала отправляться; обновили плагин, и пропала подпись у поля. Вы проверите то место, которое правили, и не проверите остальные. Люди узнают об этом раньше вас.

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

Тесты бывают разных масштабов.

• Юнит-тест (unit, «модульный»): проверяет одну маленькую функцию отдельно от всего. «Функция, которая считает стоимость заказа, при скидке 10 процентов отдаёт 900 из 1000». Быстро, дёшево, точно.
• Интеграционный тест: проверяет, как несколько частей работают вместе. «Приёмник заявок кладёт заявку в базу, и её видно в списке».
• Сквозной тест (end-to-end, e2e): проверяет весь путь человека в настоящем браузере. Открыть главную, нажать «записаться», ввести телефон, нажать «отправить», увидеть «спасибо». Самый близкий к жизни, и самый медленный.

Идею предложил Майк Кон, а хорошо она описана в статье Хэма Вокке на сайте Мартина Фаулера. Это пирамида: внизу много быстрых юнит-тестов, повыше интеграционные, на самом верху немного сквозных. Чем выше этаж, тем больше он стоит в написании и поддержке, но тем меньше вероятность, что всё зелёное, а у человека сломано. Для сайта без собственной серверной логики (статического) юнитов может не быть совсем. Зато два-три сквозных теста на главное действие остаются самой полезной проверкой из всех.

Проверьте себя: чем сквозной тест отличается от юнит-теста?

Юнит-тест проверяет одну маленькую часть отдельно, сквозной проходит весь путь человека в настоящем браузере. Поэтому сквозной ближе к реальности, но медленнее и дороже в поддержке.

Как выглядит сквозной тест

Один из самых распространённых инструментов это Playwright (его делает Microsoft). Он запускает настоящий браузер (Chromium, Firefox или WebKit) и управляет им из кода. Вот тест главного действия:

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

test('запись на консультацию', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('link', { name: 'Записаться' }).click();
  await page.getByLabel('Телефон').fill('+7 000 000-00-00');
  await page.getByRole('button', { name: 'Отправить' }).click();
  await expect(page.getByRole('status')).toContainText('Спасибо');
});

Прочитайте его как историю. Откройте страницу. Найдите ссылку по имени «Записаться» и нажмите. Найдите поле по подписи «Телефон» и введите номер. Нажмите кнопку «Отправить». Убедитесь, что в области состояния есть слово «Спасибо». Заметьте: тест ищет элементы так, как их ищет человек или диктор, по роли и подписи. Это не случайность, а совет самих авторов. Такой тест устойчив: класс могут переименовать, а подпись и роль остаются. И он заодно проверяет доступность: если у поля пропала подпись, тест не найдёт его, как не нашёл бы диктор.

Два свойства делают тесты Playwright менее хрупкими. Во-первых, автоожидание: перед каждым действием он ждёт, пока элемент появится, станет видимым и не будет перекрыт; не нужно вставлять паузу «подождать секунду». Во-вторых, он каждый раз открывает новый чистый браузер, поэтому тесты не влияют друг на друга.

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

Попробуйте на схеме: сломайте сайт, выберите, как тест ищет элементы, и посмотрите, что он заметит.

Тест проходит главное действие сайта так, как его проходит человек. Сломайте сайт любым способом, выберите, как тест ищет элементы, и запустите.

Сломать сайт

У поля телефона пропала подпись Баннер cookie перекрыл кнопку отправки Сервер отвечает ошибкой 500 при отправке Разработчик переименовал класс кнопки, внешне всё то же

По роли и подписи По CSS-классу Запустить тест

1. · Открыть главную страницу
2. · Найти ссылку «Записаться» по роли и имени и нажать
3. · Найти поле «Телефон» по подписи и ввести номер
4. · Нажать кнопку «Записаться» (найти по роли и имени)
5. · Дождаться сообщения «Спасибо» (роль status)

Нажмите «Запустить тест».

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

Проверьте себя: почему лучше искать элемент по роли и подписи, а не по CSS-классу?

Класс это деталь оформления, его могут переименовать, не изменив ничего видимого, и тест упадёт зря. Роль и подпись видит и человек, и диктор, поэтому тест, который ищет по ним, ещё и проверяет доступность.

Что тестировать на сайте

Тестировать всё не нужно: каждый тест нужно поддерживать. Начните с вопроса «чего мы никак не можем себе позволить сломать». Для сайта это почти всегда:

1. Главное действие из брифа: записаться, купить, позвонить, подписаться. Путь от главной страницы до результата. Это первый и главный тест.
2. Ошибка и пустая форма: что видит человек, если ввёл неверно. Сообщение рядом с полем, фокус на ошибке.
3. Главные страницы открываются (не 404), ссылки между разделами не ведут в пустоту.
4. Клавиатура: форму можно заполнить и отправить без мыши.
5. Языки: переключатель ведёт на нужную версию, lang страницы совпадает с текстом.
6. Согласие и политика присутствуют рядом с формой (об этом дальше в части).
7. Телефон: главное действие на узком экране (375 пикселей) работает так же.

В тестах не нужно проверять чужие сервисы (работает ли почта изнутри), пиксельное совпадение и мелкие тексты, которые вы часто меняете.

Составлять план полезно словами, до кода. Принято писать сценарии в форме «Дано, Когда, Тогда» (в англоязычной практике Given, When, Then): с чего начинаем, что делает человек, что должно произойти. Они понятны не только программисту, и их можно показать заказчику: «вот что мы проверяем при каждой правке».

Тесты и данные

Тест, который отправляет форму, создаёт настоящую заявку. Поэтому:

• Данные выдуманные. «Тест», телефон из нулей, почта на example.com (домен, зарезервированный для примеров). Настоящие имена и телефоны людей в тестах не используют, это персональные данные, и вы не вправе тратить их ради проверки.
• Тестовые заявки помечены, чтобы не попасть к настоящим клиентам: отдельное поле, служебный адрес или отдельный тестовый стенд.
• Тест не бьёт по настоящему боевому сайту чужого человека. Свой сайт проверяйте на своём стенде или на своей копии.
• Проверка форм и скрытых ловушек для ботов (следующий урок) не должна ломаться из-за тестов: тест это тоже посетитель, и ему нужен способ пройти.

Нестабильные тесты

Худший тест это тот, что иногда проходит, иногда нет без причины. Его называют нестабильным (flaky). Тест, которому нельзя верить, хуже отсутствующего: красный перестают замечать, и настоящая поломка тонет. Причины обычно такие: пауза вместо ожидания, общие данные между тестами, сеть, часы. Лечат причину, а не перезапуском до зелёного.

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

Где тесты запускаются

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

Практика

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

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

Что было не так раньше

В 2000-х сайт проверял тот, кто его сделал: открывал в трёх браузерах и «кликал». Позже появились инструменты вроде Selenium, которые умели управлять браузером, но были медленны и капризны: тесты падали сами по себе, и им переставали верить. Современные инструменты (Playwright, Cypress) сняли главные неудобства: ожидание встроено, браузеры ставятся одной командой, а тест читается как история. Но главное правило прежнее: мало тестов, зато на то, что нельзя сломать.