Браузерные тесты — единственный вид проверки, который смотрит на приложение так же, как пользователь: через настоящую страницу, настоящие клики и настоящую сеть. И единственный, который команды заводят, а потом тихо отключают.
Ниже — что стоит автоматизировать, что дешевле проверять руками и как сделать так, чтобы набор тестов пережил полгода.
Тупик: покрыть все сценарии
Первое, что пробуют, — выписать все пользовательские сценарии и автоматизировать их сверху вниз. Через месяц получается набор, который идёт долго, падает через раз и требует человека, чтобы разобрать, что именно упало.
Не работает это по трём причинам, и все они не про инструменты.
Браузерный тест дорог не в написании, а в содержании: он ломается от любой перестановки в разметке, от смены текста кнопки, от нового баннера согласия. Стоимость набора равна не сумме написания, а сумме починок.
Полное покрытие сценариями дублирует то, что дешевле проверяется ниже. Валидация формы, расчёт скидки, права доступа — всё это проверяется на уровне функций и запросов за доли секунды, а через браузер — за десятки секунд и с шансом упасть по постороннему поводу.
И третье: набор, который падает регулярно, перестают читать. После определённой доли ложных падений красный результат становится фоном, и тогда тесты не просто бесполезны — они вредны, потому что создают ощущение проверенности.
С чего начать, если тестов нет совсем
Порядок здесь важнее выбора инструмента, поэтому начинать стоит не с него.
Шаг первый — выпишите путь, поломка которого будет замечена в тот же час. Обычно это вход и одно ключевое действие после него. Один путь, а не список.
Шаг второй — пройдите его руками и запишите, что именно вы проверяете глазами на каждом экране. Это и есть проверки будущего теста; без такой записи тест обычно проверяет только то, что страница открылась.
Шаг третий — решите вопрос данных до написания кода. Откуда берётся пользователь, можно ли его создать программно, что делать с накопленными записями. Тесты, начатые без ответа на это, живут ровно до первого чужого изменения в базе.
Шаг четвёртый — добейтесь, чтобы тест проходил десять раз подряд на вашей машине и в сборке. Нестабильный с рождения тест стабильным уже не станет.
И только потом второй сценарий. Набор из одного надёжного теста полезнее набора из двадцати, которым не верят.
Что автоматизировать
Правило, которое мы считаем рабочим: браузером проверяется то, что нельзя проверить ниже.
Сквозные пути, приносящие деньги. Регистрация, вход, оформление заказа, оплата, отправка заявки. Их немного — обычно меньше десятка, — и каждый оправдывает любую цену содержания, потому что его поломка видна не в отчёте, а в выручке.
Места, где встречаются несколько систем. Возврат с внешней платёжной страницы, вход через стороннего поставщика, загрузка файла и его последующая обработка. Здесь ошибка живёт именно в стыке и не воспроизводится ни в одном отдельном компоненте.
Поведение, зависящее от браузера. Работа с историей и кнопкой «назад», сохранение состояния между вкладками, поведение при потере сети, печать.
То, что уже ломалось. Каждый инцидент, дошедший до пользователя, — кандидат на браузерный тест. Это лучший источник сценариев, чем любое планирование: он основан на том, что действительно отказывает.
Что оставить руками
Внешний вид. Автоматическое сравнение снимков экрана обещает многое и приносит поток ложных срабатываний: шрифт дорисовался иначе, тень сместилась на пиксель. Глаз человека делает это лучше и, что важнее, отличает «изменилось» от «стало хуже».
Редкие административные сценарии. Настройка, которую делают раз в квартал два человека, не стоит теста, который придётся чинить каждую неделю.
Всё, что требует настоящих внешних систем. Тест, ходящий в чужой рабочий сервис, не тест, а зависимость от чужой доступности.
Первый проход по новой функции. Пока форма меняется каждый день, тест на неё переписывается каждый день. Автоматизировать имеет смысл то, что устоялось.
Что делает набор долгоживущим
Тест не должен зависеть от разметки. Ищите элементы по назначению — по роли и видимому тексту или по явным атрибутам, поставленным специально для тестов. Селектор, повторяющий структуру вложенности, ломается при первой же перестановке.
У теста должны быть свои данные. Тест, который рассчитывает на конкретную запись в базе, падает, как только кто-то её изменит. Создавайте нужное в начале и убирайте в конце — или создавайте с уникальным признаком и не убирайте вовсе.
Ожидание — не пауза. Фиксированная задержка либо делает набор медленным, либо всё равно не спасает. Ждать нужно события: появления элемента, завершения запроса, изменения состояния.
Один тест — один сценарий. Длинный тест, проходящий половину приложения, падает посередине и не говорит ничего, кроме «где-то сломалось».
Падение должно объяснять себя. Снимок экрана, запись действий, журнал сети и консоли — сохраняются автоматически при каждом падении. Без этого разбор превращается в воспроизведение вручную, и именно на этом наборы умирают.
Нестабильный тест чинится или удаляется. Третьего состояния быть не должно. Тест, помеченный как «иногда падает», уже не проверяет ничего, но продолжает тратить время.
Как это встроить в работу
Разделите набор на две части. Короткая — сквозные пути, приносящие деньги, — идёт на каждое изменение и блокирует выкатку. Длинная — всё остальное — идёт по расписанию и не блокирует, но разбирается ежедневно.
Так вы получаете быструю обратную связь там, где она нужна, и не платите ожиданием за проверки, которые могут подождать. Граница между частями проходит по одному вопросу: остановили бы вы выкатку из-за этого падения? Если нет — тесту не место в короткой части.
Отдельный вопрос — где эти тесты запускать. На машине разработчика они должны запускаться одной командой и без ручной подготовки: если для запуска нужно поднять три сервиса и заполнить базу, их не будет запускать никто, и падение обнаружится только в сборке. Всё, что можно поднять контейнерами вместе с приложением, поднимайте вместе с ним.
Позиция редакции
Мы считаем, что браузерных тестов должно быть мало и что их число — плохая метрика: растущий набор почти всегда означает, что через браузер проверяют то, что дешевле проверить ниже. Практический вывод: начните с одного сценария, который приносит деньги, доведите его до состояния, когда он не падает без причины месяц, и только потом добавляйте второй.
Мы неправы, если у приложения нет никакого другого уровня проверок: тогда браузерный набор — единственная сеть безопасности, и его широта оправдана, пока ниже не появится хоть что-то. Но это временное состояние, а не архитектурное решение.