Как тестировать UI и что важно учитывать при тестировании UI
Что проверяют
Есть ли у кандидата система в проверке интерфейса и понимает ли он цену автотестов на UI: они самые дорогие и самые хрупкие в наборе.
Как отвечать
Перечислить, что именно проверяется, и по каждому пункту дать конкретику.
- Функциональность. Сквозные сценарии, валидация форм, поведение при ошибке сервера и потере сети.
- Состояния компонента. Пустое, загрузка, ошибка, частичные данные, очень длинный текст, тысяча строк в таблице, отсутствие прав. Половина UI-багов живёт именно в состояниях, которых нет в макете.
- Вёрстка и адаптивность. Контрольные точки, зум 200 процентов, длинные переводы, разные плотности экрана.
- Кросс-браузерность. Правильнее говорить о движках: Chromium, WebKit, Gecko. Расхождения чаще всего именно на WebKit.
- Доступность. Навигация с клавиатуры, порядок и видимость фокуса, роли и
aria-атрибуты, работа со скринридером, контраст (WCAG AA требует 4.5:1 для обычного текста и 3:1 для крупного). - Локализация и форматы. Даты, числа, валюта, склонения.
- Производительность интерфейса. LCP, CLS, отзывчивость на слабом устройстве и медленной сети.
Про автоматизацию: UI-тесты держат тонким слоем поверх юнит и API тестов, автоматизируют критичные пути, а не весь регресс. Инструменты: Playwright или Cypress для браузера, Testing Library для компонентов, axe-core для доступности, скриншотное сравнение (toHaveScreenshot, Percy) для вёрстки. Стоит оговорить, что Jest сам браузер не открывает: он гоняет компоненты в jsdom, а реальную проверку в браузере даёт только браузерный раннер.
Что снимает флакующие тесты: локаторы по data-testid и по роли вместо CSS-цепочек, ожидание конкретного состояния вместо sleep, изолированные тестовые данные, фиксированные шрифты и размер окна для скриншотов.
Где спотыкаются
Сводят ответ к «прокликать в Chrome и Firefox» и предлагают автоматизировать через UI весь регресс, после чего набор становится медленным, нестабильным и ему перестают верить.