Выполнение тестов интеграции / e2e поверх стека Kubernetes - PullRequest
Новая
       8

Выполнение тестов интеграции / e2e поверх стека Kubernetes

0 голосов
/ 24 октября 2019

Я немного покопался в том, как люди проводят интеграционные и e2e-тесты в контексте Kubernetes, и был весьма разочарован отсутствием документации и отзывов. Я знаю, что есть удивительные инструменты, такие как kind или minikube, которые позволяют запускать ресурсы локально. Но в контексте CI и с набором сервисов, он не кажется подходящим по очевидным причинам ресурсов. Я думаю, что есть большие возможности с запуском тестов для:

  • Проверка манифестов или диаграмм руля
  • Проверка правильного поведения компонента как части большего целого
  • Проверка глобального поведения продукта

Здесь речь идет не о платформе тестирования, а о среде, в которой могут выполняться тесты.

Поделитесь ли вы информациеймоя мысль? Вы когда-нибудь испытывали такие тесты? Есть ли у вас какие-либо отзывы или идеи по этому поводу?

Большое спасибо

1 Ответ

1 голос
/ 24 октября 2019

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

По сути, для решения этой проблемы мы создали сценарии, которые взаимодействуют с нашим стандартным облачным провайдером (GCloud) для создания кластера, развернитепродукта, а затем запустите тесты на него.

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

  1. Параллельность, это может показаться очевидным, но подумайте о количестве параллельных сборок, которые может выполнить ваш CI.
  2. Задержка из облака, не думайте, что вы получите мгновенный ответ на каждую команду, которую вы выполняете в облаке. Также подумайте о тайм-аутах. Если вы предлагаете продукт с множеством пакетов и сервисов, каково приемлемое время запуска?
  3. Ошибки, приводящие к сбоям сборки, это интересно. Мы видели ошибки в сборке из-за сетевых ошибок при обмене данными с нашим тестовым развертыванием. Они почти всегда переходные. Лучше всего избегать таких ситуаций, которые приводят к сбою сборки.

Одна вещь, на которую стоит обратить внимание, это то, что GitLab предоставляет некоторую документацию о том, как создавать и тестировать образы в своем конвейере CI.

...