Архитектура для интеграционного тестирования веб-расширения с веб-сервером - PullRequest
1 голос
/ 21 октября 2019

У меня есть веб-расширение, функциональность которого необходимо проверить на веб-сервере. Веб-расширение построено с использованием Webpack и должно работать на Chrome и Firefox. У него есть свои собственные модульные тесты, но важно то, что мы выполняем поведенческие тесты на веб-сервере.

В настоящее время веб-сервер представляет собой проект Docker Compose, состоящий из веб-сервера Rails (чей порт 3000 открыт дляlocalhost) и внутреннюю базу данных Postgres.

В настоящее время мы проводим тестирование немного вручную: мы встраиваем код расширения в исходный код Chrome / Firefox, загружаем этот код в Chrome и вызываем функцию внутреннего расширения, котораявыполняет различные действия. Затем мы проверяем на сервере, что все получено, как и ожидалось.

Мы хотели бы превратить это в более автоматизированный процесс, особенно сцель тестирования новых веток клиента и / или сервера друг против друга. В идеале этот процесс должен выполняться в конвейере CI (GitLab CI) всякий раз, когда создается новая ветвь клиента и / или сервера.

Мы думали о следующей настройке:

  • Будет новый репозиторий для тестирования интеграции, содержащий концентратор Selenium и экземпляр Chrome / Firefox
  • . Этот репозиторий будет извлекать соответствующий код клиента / сервера для тестирования из указанной ветви
  • Существует Selenium. тестовый скрипт, который выполняет необходимые тесты
  • Сервер запускается внутри тестовой среды, а не через Docker Compose

Причина для этого заключается в том, что сервер в настоящее время работает в проекте Docker Compose. Я думаю, что я не должен управлять этим рядом с другим проектом Docker Compose Selenium. Отсюда и идея построить его изначально. Но опять же, это означает, что требуется дополнительный процесс сборки.

Таким образом, другой вариант может выглядеть следующим образом:

Здесь яЗапустите сервер как есть, как проект Docker Compose, запустите Selenium внутри другого проекта Docker Compose, оба в одной и той же среде тестирования. Клиент будет взаимодействовать с сервером через localhost.

Я специально не хочу помещать эту функциональность в один клиент или сервер, именно поэтому я подумал об отдельном хранилище.

Мне вариант 2 кажется более разумным, но, возможно, я упускаю что-то очевидное, и может быть еще более простое решение?

Чтобы сделать вопросы более конкретными:

  1. Имеет ли смысл помещать эту функциональность в дополнительный репозиторий?
  2. Существует ли более простой подход к запуску кода сервера из этого дополнительного репозитория?
  3. Как определить, какая версия клиент / серверпроверяется в любой момент времени? Буду ли я использовать этот репозиторий тестирования в конвейере CI как сервера, так и клиента, и всегда проверять мастер соответствующего другого компонента для проверки?
...