Запуск тестов e2e при каждой фиксации при сохранении стабильности - непростая задача. В этом посте вы увидите, как наша команда в Rewire использует testim.io, чтобы проверять каждую фиксацию в нашем веб-приложении, чтобы поддерживать высокое качество продукта и ограничивать серьезные ошибки при производстве.

Ищу новый старт

Запуск тестов e2e перед объединением нашего кода с основной веткой - не новая концепция. В Rewire наш поток работает следующим образом:

  1. Разработчик открывает PR из функциональной ветки, чтобы интегрировать новый фрагмент кода в основную ветку.
  2. По крайней мере, еще один член команды должен выполнить проверку кода и утвердить его.
  3. Запустите набор автоматических тестов, включая тесты интеграции и e2e.
  4. После выполнения всех шагов разработчик может объединить код (с помощью бота marge)

Прежде чем выбрать работу с testim.io, мы использовали транспортир для запуска тестов e2e, которые выявили следующие проблемы:

  1. Разработчик должен запускать и поддерживать тесты, что может занять много времени и усилий.
  2. Тесты терпели неудачу слишком много раз, некоторые из них спорадически, что затрудняло отслеживание
  3. Тест проводился на модуле Kubernetes, что потребовало от нас установки специальных настроек общей памяти, что повлияло на стабильность и производительность теста.
  4. Код теста не был чистым, поэтому его было действительно сложно поддерживать.

Почему мы выбрали testim.io?

Разочарованные нашими предыдущими процессами автоматического тестирования e2e, мы искали лучшее решение. С самого начала нам очень понравился testim.io, поскольку его интуитивно понятная платформа могла освободить наших разработчиков от написания сложных тестов e2e и позволить им сосредоточиться на создании лучшего продукта и повышении качества в других местах. Таким образом, любой член команды может сгенерировать тест, имитирующий наиболее важный поток пользователя.

Вот некоторые из наших любимых функций:

  1. Запишите тест в реальной среде и воспроизведите его при необходимости.
  2. Детекторы элементов на основе искусственного интеллекта - тест не изменился, если мы изменили расположение или цвет кнопки, что было действительно важно для нас, поскольку мы были в процессе ребрендинга нашего приложения.
  3. Легко запускать из нашего CI (как вы уже знаете, мы используем GitLab CI)
  4. Благодаря отличному и интуитивно понятному пользовательскому интерфейсу, который предоставляет журналы консоли, сетевые журналы и визуальный помощник, точки сбоя действительно легко обнаружить.

Тем не менее, есть некоторые конфликты. Testim.io работает в своей собственной сетке селена в своих облачных экземплярах, что немного сложно для нас, поскольку требует от нас безопасного доступа к нашей временной среде извне.

Проблемы при настройке среды e2e

Чтобы сохранить стабильность нашего теста e2e, мы хотели создать среду, на которую не повлияли бы другие тесты или человеческие ошибки. Поэтому мы решили создавать новую среду для каждой новой сборки. Для этого мы использовали инфраструктуру исполнителя GitLab CI Kubernetes, чтобы смоделировать основные компоненты нашей живой среды в следующем порядке:

  1. Свежий экземпляр базы данных
  2. Экземпляр Redis
  3. Наши услуги API

Все эти сервисы были загружены как часть контекста модуля исполнителя и были недоступны из Интернета, что оказалось для нас большой проблемой, поскольку testim.io требует общедоступной конечной точки для тестов.

Кроме того, нам приходилось использовать внешние сервисы, у которых не было среды песочницы. Итак, нам пришлось имитировать их ответ как часть пользовательского потока.

Эврика - Соединяя точки

Чтобы сделать нашу среду доступной, нам пришлось предоставить 3 основных сервиса:

  1. Служба API - естественно, требует доступа к нашей временной базе данных и обеспечивает согласованное состояние для нашего веб-приложения.
  2. Веб-сервис - обслуживает наше одностраничное приложение в браузере.
  3. Служба имитации (также известная как служба e2e) - предоставляет имитации для поддержки поведения внешнего поставщика услуг, такого как платежи, хранение и т. Д.

Раскрытие нашей архитектуры e2e

На диаграмме выше вы можете найти наш набор решений для вышеупомянутых проблем. Каждая услуга была представлена ​​по-разному:

  1. Используя туннели Cloudflare Argo, мы смогли предоставить доступ к нашему API и сервисам Mocking в Интернет, используя временное DNS-имя. Для этого мы создали специальный образ докера, который включает двоичный файл туннеля Argo и может получать необходимые сертификаты из нашего экземпляра HashiCorp Vault. Этот образ был базовым для исполнителя, запустившего тест.
  2. Мы смогли предоставить в Интернет самую последнюю версию нашего веб-приложения, которая была настроена для доступа к определенной конечной точке API (как показано в нашей статье о создании промежуточных сред с использованием Cloudflare Workers) . В этом случае нам пришлось предоставить testim.io соответствующий URL-адрес веб-приложения и версию API для тестирования.

Теперь все, что осталось сделать, это запустить интерфейс командной строки testim.io с соответствующими переменными, чтобы получить доступ к веб-приложению и соответствующим службам, которые теперь доступны извне.

Звучит просто, правда?

Что ж, в реальной жизни ничего не дается легко. Как мы быстро узнали, необходимо было решить множество проблем, чтобы провести тест безупречно, например:

  1. Организация услуг. Мы должны были убедиться, что наши спутниковые сервисы запускаются только после того, как будет загружен основной сервис-исполнитель. Поскольку этим службам требовался некоторый артефакт сборки, который копировал основной контейнер в модуле, чтобы запускаться как часть процесса начальной загрузки.
  2. Время начальной загрузки туннеля Argo непредсказуемо, поэтому нам пришлось протестировать подключение к туннелю перед запуском интерфейса командной строки testim.io.
  3. Проблема CORS - к сожалению, эту ошибку найти было непросто. При запуске теста testim.io отправляет заголовок источника, отличный от основного URL-адреса, поэтому нам пришлось поддерживать настраиваемые заголовки источника при ответе нашими заголовками CORS.
  4. Открытие журналов при сбое, поскольку тест не всегда проходил, нам пришлось предоставить разработчикам журналы временных служб. В этом случае мы не подключили сервисы к нашей центральной системе ведения журналов, поэтому для каждой сборки мы открывали артефакты, содержащие журналы.
  5. Журналов было недостаточно. Разработчикам нужно было видеть содержимое базы данных, в которой хранится состояние приложения. Поэтому мы добавили дамп БД при сбое и восстановленный скрипт.
  6. Конфликт DNS - поскольку несколько тестов могут выполняться параллельно, и во избежание конфликтов нам необходимо рандомизировать имя туннеля Argo, поскольку два туннеля Argo не могут работать с одним и тем же именем. Наличие двух туннелей Argo с одинаковыми именами проблематично, поскольку тест может использовать неправильный API.
  7. Загрязнение DNS - каждый тест создает несколько записей DNS, поэтому нам пришлось очистить эти записи, чтобы избежать нежелательной почты у нашего поставщика DNS.

После преодоления всех этих проблем мы получили довольно стабильный и быстрый тест e2e, который охватывает основной пользовательский поток на каждом конвейере запроса на вытягивание.

Наконец-то мы остались довольны результатами

Объединив набор инструментов, которые мы выбрали, мы смогли создать эффективный тест e2e, который проверяет нашу последнюю версию, и в то же время радует наших разработчиков, позволяя им быстро выполнять поставку.

  • Testim.io позволяет нам создавать стабильные тесты, которые легко создавать, запускать, поддерживать и отлаживать.
  • GitLab CI предоставляет инфраструктуру для создания и запуска сложной архитектуры тестирования.
  • Рабочие Cloudflare упрощают доступ к веб-приложению и снижают нагрузку на серверы сборки.
  • Наконец, туннель Argo упрощает доступ к нашим внутренним сервисам на платформе testim.io.

Вот и все. Следите за новостями из этой серии: мы поговорим о том, как мы отслеживаем наших рабочих Cloudflare и какая настраиваемая инфраструктура была создана для этой цели.