Тестирование фронтенда
2026-02-26 20:19 Diff

E2E Практики

Hexlet

Что вообще проверяем?

  • Соответствие макету
    • поддержка retina-мониторов
    • pixel-perfect
    • контраст / следование style guides
  • Проверка на разных разрешениях экрана
    • десктопной
    • мобильной
    • адаптивных
  • HTML / CSS / JS
  • Шрифты
  • Работа в разных окружениях
    • кроссбраузерность
    • работа на разных устройствах
    • работа на разных операционных системах
    • корректная работа с разной скоростью интернета
    • корректная работа при включенном расширением AdBlock в браузере
    • анимация / прокрутка / sticky элементы / плавность
  • Контент
    • большой текст
    • орфографии
    • изображения

Что мы делаем

  • определяем пользовательские сценарии
    • логин
    • создание аккаунта
    • отправка сообщений
    • покупки
  • автоматизируем сценарии
  • тестируем тесты
  • учитываем кроссбраузерность

Даже не пытаемся тестировать

  • CAPTCHA
    • Отключаем капчу в тестовом окружении
    • Добавьте хук, позволяющий тестам обходить капчу
  • Двухфакторная аутентификация
    • Отключаем 2FA в тестовом окружении
    • Отключаем 2FA для определенных пользователей в тестовом окружении Вы можете использовать учетные данные этого пользователя при автоматизации
    • Отключите 2FA для входа в систему с определенных IP-адресов Мы можем установить эти IP-адреса для наших тестовых машин

Даже не пытаемся тестировать

  • вход на сервисы вроде Gmail и Facebook, с помощью WebDriver это делать не стоит
    • это против условий использования этих сайтов
    • вы рискуете потерять учетную запись
    • это медленно и ненадежно
    • используйте сервис, предоставляющий API для создания тестовых учетных записей
    • работа с API может усложнить работу, но это окупится скоростью, надежностью и стабильностью
  • геттеры / сеттеры
  • нечто нерелевантное / внешнее / постороннее
  • Поддержка X браузеров на Y платформах - затратно
  • Ведет к ловушке поддержки X×Y реализаций
  • Делайте ваши тесты как можно более устойчивыми === тесты не будут сразу ломаться при любом изменении
  • Ориентируйтесь на перспективу конечного пользователя
  • Мыслите как пользователь
  • Сосредоточьтесь на особенностях приложения, а не на его реализации
    • Чего пытается достичь пользователь?
    • Легко ли найти то, что он(а) ищет?
    • Достигнет ли пользователь своей цели в несколько простых шагов?
  • Избегайте нагромождений селекторов
  • Убедитесь, что у элемента есть стабильный селектор, который не изменится в следующей версии приложения
  • Выбирайте элементы страницы с умом
    • ID
    • CSS селекторы
    • data-аттрибуты
    • Доступность (aria)
  • Тесты не должны зависеть друг от друга
  • Не игнорируйте неустойчивые тесты, которые возвращают разные результаты без каких-либо изменений в коде
  • Прогоняйте тесты еще раз, прежде чем заводить issue
  • Убедитесь, что у вас есть подходящие тестовые данные
  • Напишите отчет
  • Проведите дымовое тестирование
  • Разработайте наборы тестов на согласованность
  • Постройте хорошую организационную структуру
  • Нашли баг? Напишите тест, а затем исправьте его
  • Ждите, не спите
  • Тест должен быть простым
  • Используйте CI / уведомления
  • Используйте линтеры, следуйте стилям кодирования и т.д.
  • eslint-plugin-jest может предупреждать, когда в тесте нет утверждения (assertion)
  • Вы можете группировать тесты тегам вроде #smoke
  • Антипаттерн: Вы читаете отчет => просматриваете код

Подмена бекенда

Mock Service Worker (msw)

  • Передовой мок-API
  • Перехватывает запросы на сетевом уровне, а не на уровне приложений
  • Вы можете использовать axios, fetch, xhr, что угодно
  • Вы можете использовать его для разработки и отладки
  • Поддержка REST API и GraphQL
  • Выполнение на стороне клиента
  • Поддержка TypeScript
  • Независимый от фреймворков

Исправление ответов сервера

Page Object Pattern

  • много тестов
  • много кода в тестах
  • сложно понимать структуру и флоу

Page objects

  • упрощение разработки
  • упрощение поддержки
  • Высокоуровневый API
  • DRY-принцип: создаем переиспользуемый код избегая повторов
  • page object — обертка над HTML страницей или ее частью

  • Ее API специфично для конкретного приложения

  • Манипулируйте элементами страницы, не углубляясь в HTML

  • findElementWithClass('album') => selectAlbumWithTitle()

  • findElementWithClass('rating').setText(5) => updateRating(5)

Преимущества

  • Если UI страницы изменится
    • тесты изменять не надо
    • нужно изменить код в page object
  • Все изменения касающиеся поддержки этого нового UI находятся в одном месте
  • Все доступные операции или сервисы на странице хранятся в одном месте вместо того, чтобы дублироваться во всех тестах
  • Код тестов легче понять
  • Существует четкое разделение между кодом тестов и кодом, относящимся к html-странице, вроде селекторов и верстки

Selenium

Правила

  • Сами page object никогда не должны ничего тестировать
  • Page object содержит представление страницы
  • Никакой код, связанный с тем, что тестируется, не должен находиться внутри объекта страницы
  • Исключение: убедитесь, что страница отображена верно
  • Доступные методы представляют операции, возможные на страницы

  • Try not to expose the internals of the page

  • Не создавайте объект для всей страницы, только значимые элементы

    • верхний и нижний колонтитулы, список пользователей, логин и т.Д
  • Общедоступные методы представляют услуги, предлагаемые на странице

  • Старайтесь не показывать внутренности страницы

Если поведение должно отличаться

Можно наследоваться

Минусы e2e

  • медленные
  • нестабильные
  • непредсказуемое поведение
  • изменение UI ломает тест
  • нельзя посмотреть строчку где тест упал