Быстрое визуальное тестирование встроенного контента

Встраивание контента на сайт клиента - это привилегия. У вас есть прямые средства изменить впечатления каждого посетителя. К этому нельзя относиться легкомысленно.

В прошлом месяце Klaviyo выпустила капитальный ремонт набора функций нашей формы подписки, чтобы упростить встраивание эффективных форм подписки на веб-сайты наших клиентов. Это был захватывающий продукт, требующий решения множества интересных задач.

На большинстве веб-сайтов электронной коммерции есть всплывающие или всплывающие модальные формы регистрации, которые появляются для пользователя и предлагают им зарегистрироваться для будущего маркетинга. Поскольку их обычно создают маркетологи, мы создали простой в использовании инструмент, с помощью которого они могут создавать формы регистрации в редакторе перетаскивания. Затем, после установки на их сайт фрагмента короткого кода, мы доставляем эти модальные окна посетителям, когда они просматривают.

Наш контент должен быть надежным, чтобы формы, которые наши клиенты видят в дизайнере, были такими же, как те, что они видят на своих сайтах.

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

Мы не контролируем, какой CSS или JavaScript будет на веб-сайте наших клиентов. Мы столкнулись с пользовательскими переопределениями методов в Array и Object, CSS, например div{ width: 100% }, и других.

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

Войдите в визуальное регрессионное тестирование

Визуальные регрессионные тесты предназначены для выявления дрейфа в визуальном представлении контента. Они не предназначены для замены модульных тестов или работы в качестве тестов в стиле Selenium. Визуальные регрессионные тесты - не инструмент для тестирования вашего API.

Наши цели:

Набор тестов должен работать менее 30 секунд.
Результаты набора тестов должны быть одинаковыми при нескольких запусках.
Тесты должны содержать достаточно подробностей, чтобы начать отладку.
Тесты должно быть легко писать

Что мы используем:

g raphcool’s Chromeless для запуска Chrome без головы в AWS Lambda
Образ-шутка-снимок Amex для создания визуальных различий
Дженкинс для непрерывной интеграции

Запустив Chrome без головы в Lamba, мы можем запускать множество тестов, асинхронно останавливая время выполнения. Фактически, это настолько быстро (и дешево), что мы можем запускать эти тесты с помощью функции наблюдателя jest! Обычно мы этого не делаем, но это, безусловно, помогает при отладке проблемы.

Примеры из реальной жизни!

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

Встраивание контента на сайт клиента - это привилегия.

Пример 1. Различные значения шрифтов ОС по умолчанию

Экземпляр chrome без заголовка в Lambda может не иметь ожидаемых шрифтов. Желательно явно указать семейства шрифтов, которые вам понадобятся.

На изображении ниже мы показываем разницу между нашими правильными шрифтами и тем, что наша форма отображает, когда эти шрифты отсутствуют.

Пример 2. Незначительное изменение заполнения из-за избирательности CSS

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

Пример 3: преобразования CSS

Когда мы показываем наши формы в мобильном представлении, мы пропорционально уменьшаем размер формы с помощью CSS transform-origin.

Здесь мы видим изменение с transform-origin: left center; на transform-origin: left top;.

Общие препятствия

Mocking API

Наши API разбиты на отдельные модули. Мы решили сделать сборку javascript для тестирования изображений, которая заменяет эти модули API на проверенные ответы. Это означает, что мы можем создать наши клиентские пакеты со встроенными детерминированными ответами API.

Мы использовали treehaking webpack для условной загрузки этих имитированных версий. Наши визуальные тесты могут загружаться без каких-либо внешних зависимостей.

Шрифты

Возможно, у вас нет шрифтов, которые вы ожидаете от среды Linux, которую использует Lambda! Не забудьте добавить нужные шрифты по мере необходимости.

Это также означает, что если вы используете Chrome без головы локально в OS X, вы можете получить несколько разные результаты из-за разных настроек ОС по умолчанию.

Параллельное выполнение тестов

У Jest есть особые критерии, когда он запускает тесты параллельно. Взгляните на следующую проблему github для получения более подробной информации.

Https://github.com/facebook/jest/issues/5818

Обслуживание связанных активов

Из-за того, что Chrome работает без головы на Lambda, у нас не будет доступа к файлам на хосте (CI или на вашем локальном компьютере). Чтобы иметь возможность загружать свои статические ресурсы (JS Bundle) в безголовый экземпляр Chrome, вам необходимо, чтобы он был доступен по «общедоступному URL-адресу» (он должен быть доступен на основе групп безопасности Lamba).

Мы справляемся с этим двумя способами

Локальная разработка - мы используем localtunnel / ngrok для создания обратного прокси в нашей локальной среде. Затем в нашем ./config файле (в примере выше) мы устанавливаем связанный testDomain. Я настоятельно рекомендую использовать node-config для вашей конфигурации.
Непрерывная интеграция Jenkins - в CI мы создаем наш пакет JS и копируем его в корзину S3 в каталог, который соответствует ветви PR /.

Затем мы устанавливаем testDomain через переменную среды, которая читается в ./config. Таким образом, Chrome в AWS может легко попасть в корзину S3 и запускать тесты параллельно.

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

stage('Visual Regression Tests') {
  steps {
    sh 'export VISUAL_REGRESSION_BUCKET_URL = "http://test-assets-foo.s3-website-us-east-1.amazonaws.com/"'
sh 'export VISUAL_REGRESSION_PATH = "${env.CHANGE_ID ? \'visual-regression/PR/\' + env.CHANGE_ID : env.BRANCH_NAME }"'
sh 'TEST_DOMAIN=${VISUAL_REGRESSION_BUCKET_URL}${VISUAL_REGRESSION_PATH} NODE_ENV=test yarn webpack --mode production'
withAWS(credentials:'aws-creds') {
      s3Upload(
        file: 'test/',
        bucket: 'test-assets-foo',
        path: "${env.VISUAL_REGRESSION_PATH}/dist/",
        metadatas: ['Content-Type: text/javascript; charset=utf-8'],
        cacheControl: 'no-cache, no-store, must-revalidate',
      )
    }
withCredentials([string(credentialsId: 'api-key', variable: 'VISUAL_REGRESSION_API_KEY')]) {
      sh 'TEST_DOMAIN=${VISUAL_REGRESSION_BUCKET_URL}${VISUAL_REGRESSION_PATH} yarn test-images --ci'
    }
  }
}

Тайм-ауты

Иногда таймаут наших лямбда-функций в середине теста. Мы не нашли решения этой проблемы, кроме повторного запуска теста. Следующая проблема с github подробно описана, если у вас возникла аналогичная проблема.

lambda Необработанное обещание отклонено ECONNREFUSED · Проблема № 259 · prismagraphql / chromeless
Я использую chromeless для lambda и периодически получаю следующую ошибку: (узел: 1)… github.com

Пример тестовой оболочки

Следующий фрагмент кода - это измененный помощник, призванный помочь нам ускорить написание этих тестов. Внизу я добавил пару простых тестов.

Обратите внимание: это упрощенный пример, который не предназначен для «копирования / вставки».

Другие полезные источники

Нам очень помогли следующие ресурсы:

В заключении

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

Я определенно рекомендую попробовать, если у вас есть вопросы, не стесняйтесь обращаться к нам!