Python: Selenium
Теория: Настройка браузера
Когда тестов становится много, важно, чтобы браузер вёл себя одинаково на любой машине — в докере, на CI и локально. Если этого не сделать, начинаются случайные падения: у кого-то кнопка уехала в «бургер», у кого-то открылось окно разрешений, а у кого-то не скачался файл. Дальше — самые нужные настройки, которые делают браузер предсказуемым.
Headless-режим
Headless («безголовый») режим — это способ запустить браузер без окна. Он экономит время и подходит для серверов, где нет экрана. При этом всё работает как обычно: страница загружается, элементы ищутся, клики выполняются.
Если размер окна не указать, сайт может перестроиться под мобильный экран — и нужная кнопка исчезнет. Поэтому ширину всегда задают явно.
Размер окна
Адаптивные сайты подстраивают верстку под ширину экрана. Меняются не только стили, но и сама структура DOM: элементы могут скрываться, переноситься, объединяться в «бургер»-меню. Для автотеста это превращается в проблему — один и тот же локатор в мобильной версии просто не существует. Поэтому размер окна нужно зафиксировать заранее.
Когда браузер запускается без указания размеров, он может открыться в случайной ширине — например, 900 px в контейнере CI. В таком виде сайт может сразу перейти на мобильную версию, скрыв часть кнопок. Команда set_window_size() задаёт точную геометрию окна и гарантирует одинаковый DOM на всех машинах.
Если тест нужно прогнать на разных разрешениях, делают несколько запусков с разными размерами. Например, один раз проверяют поведение на десктопе (1366×768), второй — на мобильной ширине (390×844). Это позволяет убедиться, что верстка не ломается, а функциональность сохраняется.
При уменьшении окна до мобильных размеров можно проверить работу адаптивных элементов: скрываются ли блоки, появляется ли «бургер»-меню, корректно ли работает форма входа на маленьком экране.
Фиксированный размер важен и в headless-режиме. В нём браузер не имеет настоящего окна, поэтому по умолчанию выбирает минимальную ширину — около 800 px. Из-за этого на CI тесты видят не ту страницу, что локально. Решение простое: добавить аргумент --window-size=1366,768 при запуске.
Если тест проверяет мобильную вёрстку, ширину можно уменьшить, а user-agent — подменить, чтобы сайт отдал мобильный шаблон. Это даёт полный контроль над интерфейсом и устраняет случайности, связанные с разными экранами и окружением.
Загрузка куков перед входом
Процесс авторизации через форму — один из самых нестабильных участков в UI-тестах. На проде могут появляться капчи, всплывающие подсказки, анимации, проверки двухфакторной аутентификации. Всё это делает тест длинным и хрупким: любая задержка — и он падает. Чтобы избавиться от этого, можно заранее сохранить cookie авторизованного пользователя и восстанавливать сессию напрямую.
Cookie — это данные, по которым сайт «узнаёт» пользователя: идентификатор сессии, токен авторизации, настройки языка, тема интерфейса. Если их загрузить до открытия защищённой страницы, сервер воспримет браузер как уже вошедшего пользователя.
Но важно помнить: браузер принимает cookie только для текущего домена. Поэтому первым шагом нужно открыть любую страницу этого сайта — иначе Selenium не сможет их добавить.
Файл cookies.json можно получить один раз вручную, после обычного входа в систему. В Python это удобно сделать с помощью простого скрипта: открыть страницу, войти, вызвать driver.get_cookies() и сохранить результат в файл.
Теперь авторизация больше не нужна — при каждом запуске теста куки будут подставляться автоматически.
Такой подход решает несколько проблем:
- ускоряет тесты — нет формы входа и ожиданий;
- устраняет капчи и двухфакторку;
- делает сценарий стабильным: если сессия действительна, переход всегда успешен.
Есть важные нюансы. Если домен или поддомен изменился, cookie не добавятся — браузер их проигнорирует. Также срок действия cookie может истечь. В этом случае тест нужно один раз перезапустить вручную, чтобы обновить файл cookies.json.
В сложных проектах куки хранятся в фикстуре Pytest и автоматически подгружаются в каждом тесте, который требует авторизации.
Пользовательские профили и аргументы
Иногда два одинаковых теста ведут себя по-разному. На одной машине браузер открывает всплывающее окно с запросом уведомлений, на другой — страница внезапно на английском, а на третьей — кнопка смещена из-за другого масштаба интерфейса. Причина проста: настройки браузера по умолчанию отличаются. Чтобы зафиксировать поведение, используют аргументы и профили.
Аргументы (--lang, --headless, --disable-notifications) управляют запуском браузера и задают его поведение с нуля. Профиль — это папка, где браузер хранит состояние между сессиями: сохранённые куки, логины, темы, разрешения, историю.
Пример для Chrome
В этом примере создаётся временный пользовательский профиль — отдельная папка, в которой браузер хранит свои данные только во время одного запуска. После завершения теста профиль удаляется. Такой подход обеспечивает полностью чистое окружение: в нём нет старых cookie, кеша, истории, сохранённых логинов или расширений, которые могут повлиять на тест. Каждый прогон начинается «с нуля».
Пример для Firefox
Для Firefox логика та же — браузер настраивается так, чтобы каждый запуск был независимым. Здесь вместо аргументов применяются настройки профиля (preferences). Они позволяют управлять поведением движка напрямую: отключать уведомления, задавать язык, определять папку для загрузок. Такая конфигурация избавляет тесты от случайных диалогов и сохраняет одинаковое поведение на всех машинах.
Такой профиль гарантирует стабильное поведение Firefox: никаких всплывающих окон, предсказуемый язык и папка загрузок, одинаковый результат на всех платформах.
Минимальный набор флагов, который стоит добавить в каждый проект
Эти пять строк устраняют большую часть случайных падений, не связанных с продуктом.
Управление загрузками
Когда автотест скачивает файл, браузер по умолчанию открывает системное окно с вопросом: «Открыть или сохранить?». Для человека это удобно, но для теста — катастрофа. Selenium не умеет взаимодействовать с такими диалогами, поэтому сценарий зависает. Чтобы скачать файл автоматически, нужно заранее указать папку загрузки и отключить подтверждения.
Chrome
В Chrome управление загрузками выполняется через словарь prefs. В нём задаются настройки браузера, которые Selenium применяет при запуске.
- Параметр
download.default_directoryопределяет, куда сохранять файлы. download.prompt_for_downloadотключает всплывающий диалог.plugins.always_open_pdf_externallyзаставляет Chrome скачивать PDF, а не открывать их во вкладке.
Firefox
Firefox настраивается иначе: через set_preference. Там используется список MIME-типов файлов, которые нужно сохранять без вопросов.
Почему это важно
Если не указать настройки, Chrome или Firefox покажут модальное окно, которое блокирует тест. Selenium не сможет закрыть его или кликнуть по странице, потому что управление передано диалогу. С явными настройками загрузки тест идёт дальше, файл сохраняется в известную директорию, и можно проверить результат.
Например, после скачивания можно убедиться, что файл действительно появился в нужной папке:
В итоге один и тот же сценарий стабильно работает и локально, и на CI — без случайных зависаний и ручных действий.
Настройки языка и User-Agent
Если сайт показывает разные версии на русском и английском, важно зафиксировать язык. Также можно задать свой User-Agent, чтобы получить нужную версию страницы.
Мобильная эмуляция
Большинство современных сайтов имеет адаптивную вёрстку — при узком экране меню превращается в «бургер», блоки перестраиваются в колонку, а часть элементов скрывается. Проверять такое поведение вручную на телефоне неудобно, а запускать Selenium на реальном устройстве — слишком сложно. Решение — включить мобильную эмуляцию прямо в браузере, например в Chrome.
Эмуляция создаёт среду, в которой браузер ведёт себя как смартфон: меняет размеры экрана, плотность пикселей и подменяет user-agent. Сайт думает, что его открыл телефон, и отдаёт мобильный шаблон. Это позволяет проверить мобильную вёрстку, не выходя за рамки обычного автотеста.
Пример для Chrome
После запуска сайт откроется в мобильной верстке: появится компактное меню, кнопки изменят размер, а навигация будет адаптирована под вертикальный экран.
Проверка поведения интерфейса
В таком режиме можно тестировать мобильные элементы — «бургер»-меню, скрытые кнопки, свайпы, формы ввода на маленьких экранах. Например, автотест может проверять, что меню разворачивается по клику:
Такой тест подтвердит, что адаптивная навигация работает корректно и пользователю доступен весь функционал.
Готовые профили устройств
В Chrome можно использовать встроенные шаблоны: "deviceName": "iPhone SE", "Pixel 7", "Galaxy S8+" и другие. Это удобнее, чем задавать размеры вручную:
Общая фикстура для Pytest
Чтобы не прописывать всё в каждом тесте, настройки выносят в фикстуру.
Теперь в тестах можно просто писать:


