Проблема
«У нас тысячи юнит-тестов и около сотни интеграционных. Интеграционные, в нашем случае в виде дымовых тестов, позволяют автоматически проверять веб-функции на нужных платформах и в браузерах. Автоматизированные дымовые тесты удобны тем, что позволяют проверять важные функциональные возможности, не нанимая целую армию тестировщиков-ручников, которые сидели бы и многократно выполняли одни и те же действия.
С точки зрения технической реализации: используем фреймворк Webdriver с тестами Selenium на JavaScript.
Мы создали инфраструктуру, которая позволяет запускать отдельные тесты из набора локально, а также передавать их на выполнение в удаленные тестовые окружения.
- BrowserStack дает возможность масштабированно запускать тесты на различных реальных девайсах, браузерах и операционных системах.
- Что касается частоты выполнения, то мы проводим дымовые тесты в нескольких конфигурациях сборок. При каждом обновлении удаленной ветки до слияния; после слияния ветки с мастер-веткой; и ежечасно на мастер-ветке (так называемый «auto-smoke») перед глобальным развертыванием.
- Если любой из дымовых тестов постоянно падает на любом из этапов, мы запрещаем слияние, пока все тесты не пройдут. Мы серьезно относимся к результатам тестов, потому что ни один тест не может и не должен быть красным, так как это препятствует развертыванию нового кода, пока мы не смогли убрать причину ошибки.
Хрупкость тестов
Она создает ряд проблем для владельцев тестовой веб-инфраструктуры: хотя тесты Selenium быстрее, чем действия человека, они медленнее, чем небольшие программные jest-тесты. Тест, выполняемый по сети, с множеством изменяемых блоков кода, каждый из которых зависит от другого, может неожиданно упасть из-за случайного сбоя сети, самого приложения или его платформы. Все еще сложнее, когда не мы контролируем базовое оборудование, на котором выполняются тесты. Мы сталкиваемся с проблемой хрупкости — несколько тестов (из сотен) периодически падали, но это не свидетельствовало о реальных проблемах в коде. Такая нестабильность приводила к потере доверия к результатам тестов.
Разработчики часто игнорировали красные дымовые тесты и сливали свой код в мастер-версию, а позже обнаруживали иногда, что этот якобы «просто нестабильный» тест сигнализировал о реальной проблеме. Поиск причин, откат статусов, разбор — все это отнимало много времени и напрягало. Можно установить специальный конфиг для повторного теста на уровне модулей, но что если устройство, на котором вы запускаете тест, потеряет соединение или браузер не откроется?
Потенциальным решением является полный перезапуск тестовой сборки. Однако это непрактично, поскольку занимает много времени. Другим решением мог бы быть плотный ручной контроль проблемного теста его создателем. Например, при выполнении тестов делаются снимки экрана, и можно промотать запись теста или выполнить его у себя. Но это все равно приводит к падению доверия к тестовой инфраструктуре и тратам дорогостоящего времени инженеров.
Однако нам удалось решить проблему нестабильности тестов, в первую очередь за счет использования повторных запусков на уровне девайсов. Мы также разработали визуальный инструмент — тепловую карту успешных тестов, называемую Test Dashboard, для отображения показателей успешности/неуспешности выполнения с течением времени.
Инфраструктура
Основой тестовой инфраструктуры является возможность запускать тесты Selenium Webdriver через туннель BrowserStack, платформы, которая позволяет тестировать twitter.com в браузерах, операционных системах и реальных девайсах. Примерно так устроена:
- Webdriver.io позволяет задавать конфигурации для наших JavaScript Selenium-тестов.
- Wdio-browserstack-service — пакет с открытым исходным кодом, разработанный одним из наших инженеров; позволяет передавать данные в/из Browserstack.
- Плагин Junit Reporter Webdriver помогает сохранять данные о результатах тестирования в XML.
С помощью Browserstack мы можем указывать, на каких устройствах тестировать сайт. После выполнения тестов результаты отправляются обратно и сохраняются в XML. Затем считываем их и преобразуем в JSON-объекты для дальнейшей обработки.
Решение — селективный retry
Добавление функции повторных попыток выполнения (retry) на уровне устройства решило нашу давнюю проблему, связанную с нестабильностью тестов. Мы программно проверяем сбои, считывая XML-файлы, и повторно запускаем отдельно тот тест, который не прошел, а не весь набор.
До этих автоматических ретраев на уровне устройства, средний показатель успешности сборки для премастер-веток в течение двух недель составлял около 75 %; теперь у нас стабильный показатель успешности > 90 %. Поскольку повторные попытки также автоматические разработчику не нужно перезапускать сборку вручную, и ждать, пока весь набор будет выполнен снова. Мы повторяем только те тесты, которые не прошли в первый раз.
Результаты тестирования изображены ниже. Это скриншот нашей панели Smokes Dashboard. Она показывает, как наши интеграционные тесты выполняются в течение определенного времени, а также их результат.
