Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Перевод статьи «How a Missing Timezone Broke My Test Automation».
Будучи инженером-тестировщиком, задумывались ли вы о том, насколько надежна ваша среда автоматизации? Или, возможно, сталкивались с проблемой нестабильности, когда что-то идеально работает локально, но необъяснимо сбоит в тестовой среде?
В этой статье я хочу поделиться небольшим, но крайне важным открытием. На первый взгляд, ситуация весьма тривиальна. Однако если упустить ее из виду, то можно запросто сломать всю автоматизацию тестирования.
Содержание
Сама ситуация
Я настроил окружение для запуска автотестов в сети. Все работало нормально; тесты — стабильно зеленые. Я переключился на автоматизацию другого функционала. Но чем масштабнее становилась автоматизация, тем заметнее выделялась странность: одна конкретная функция стабильно выдавала ошибку, тогда как прочие тесты завершались успешно.
Возник закономерный вопрос: почему так?
Сначала я грешил на обычные вещи: измененный селектор, медленная загрузка, скрытый элемент – в общем, классический набор. Но в данном случае ничего из этого не подходило. Ошибка возникала примерно так:
- войти в систему
- открыть меню
- нажать на кнопку – и вот вам ошибка.
Нажать на кнопку – что же в этом сложного? И почему возникает ошибка?
Я решил копнуть глубже.
Отладка
Я начал отладку, исходя из самой ошибки. Она была вот такой:
Но неужели действительно проблема с интернетом?
Запустил несколько тестов локально – все работает. Идеальное выполнение. Запустил их в тестовой среде (внутри Docker) – опять та же ошибка.
Что-то явно не так.
Я пользуюсь Robot Framework с SeleniumLibrary, и там есть некоторые ограничения: нельзя напрямую просмотреть сетевой журнал. Поэтому я переделал тест под Browser (на базе библиотеки Playwright), в котором виден сетевой трафик.
{
"startedDateTime":"2025-04-18T02:34:56.580Z",
"request":{
"method":"GET"
},
"response":{
"status":200
}
}После обновления я получил следующий отклик сети:
- Статус: 200
- Корректное тело ответа
Вроде бы, все хорошо.
Но… тест не пройден. Так в чем же ошибка?
Аномалия
Я внимательно изучил скриншоты при ошибке и заметил одну небольшую, но очень важную деталь:
Локальная версия:
1. Панель навигации отображается.
2. Дата отображается в правильном формате (локализована).
Версия в Docker:
1. Панель навигации пропадает.
2. Дата отображается в формате ISO.
Получается, что данные с бэкенда поступают корректно. Но на фронтенде они отображаются по-разному, в зависимости от того, в какой системе смотреть.
Основная причина
Так куда же пропала панель навигации? Почему изменился формат даты? И почему выдается ошибка «нет интернета», когда проблема явно не в нем?
Я даже попробовал поменять способ запуска тестов: перешел с одного Docker-образа (код + браузер в одном контейнере) на настройку Selenium Grid (разные контейнеры для кода и браузера). Но проблема никуда не делась.
Это поднимает куда более глубокий вопрос:
Действительно ли мы, инженеры-тестировщики, четко понимаем, как именно наше приложение обрабатывает разные данные (например, отображение даты и т.д.)?
После беседы с разработчиком я выяснил, что разные страницы по-разному обрабатывают формат отображения даты. Причем, некоторые полагаются на локальные настройки браузера.
Это объясняет, почему на других страницах все было хорошо: лишь одна конкретная функция оказалась чувствительной к форматированию даты, а в Docker-контейнерах по умолчанию вообще нет настроенного часового пояса.
Решение
Поняв, наконец, что проблема в отсутствующих настройках часового пояса, я проверил свои файлы в Docker. Так и есть – часовой пояс нигде не задан.
Я добавил переменную среды для часового пояса и…
Тест пройден!
Перепроверил все в настройках Selenium Grid…
Там тоже все успешно.
Заключение
Этот опыт преподал мне важный урок:
Даже такая мелочь, как настройка часового пояса в Docker-контейнере, может сильно повлиять на тестирование.
Создавая архитектуру по автоматизации, следите за максимальной идентичностью окружения – вплоть до часового пояса.