API-тестирование контейнерных микросервисов с помощью Karate

Я пытаюсь использовать карате (https://github.com/intuit/karate) в качестве ключевого компонент в общей стратегии тестирования для тестирования контейнерных облачных микросервисов. Предполагая, что и тестируемый микросервис, и Karate имеют свои собственные контейнеры, процесс выглядит следующим образом:

  1. Получите каждый контейнер для локального развертывания
  2. Создайте (через gradle) компоненты в контейнере Karate (предположим, что для наших макетов требуются классы Java)
  3. Разверните (через gradle) макеты и запустите их в автономном режиме
  4. Внедрить информацию о макетах в YAML микросервиса
  5. Сборка и развертывание микросервиса локально
  6. Запускать тесты Каратэ (передача информации о макетах и ​​/ или окружении) через интерфейс командной строки.

Мой первый вопрос: хорошая это идея (TM) или плохая идея (TM). На первый взгляд это кажется разумным и достижимым, но мне интересно, пытаюсь ли я использовать каратэ таким образом, чтобы оно никогда не предназначалось для использования. Я играл с идеей сохранить все элементы Каратэ (включая фиктивный сервер) в самих тестах, но затем шаги № 3-5 должны были бы ввести фиктивную информацию в микросервис, а затем запустить команды для создания и развертывания микросервиса. все в рамках набора тестов, который мне показался плохой идеей (TM). Лучше вместо этого сделать это как часть конвейера в работе Дженкинса, верно?

Мой второй вопрос - как лучше всего экспортировать макеты, файлы и зависимости Java для внешнего использования (для поддержки шагов 2–3), например, вот файловая структура:

.
+-- build.gradle
+-- src
|   +-- main
|       +-- java
|           +-- JWTSigner
|           +-- PEMHelper
|       +-- resources
|           +-- private-key.pem
|           +-- public-key.pem
+-- test
|   +-- main
|       +-- java
|           +-- api
|               +-- cats
|                   +-- cats.feature
|               +-- dogs
|                   +-- dogs.feature
|               +-- AllTestsRunner.java
|           +-- mocks
|               +-- mock-auth.feature
|           +-- templates
|               +-- public-key.json
|       +-- resources
|           +-- lolcats.pdf
|           +-- loldawg.jpg

Итак, здесь mock-auth.feature нужны материалы как в src/main, так и в src/test/templates. Мне удалось поиграть с задачами gradle и скопировать необходимые материалы в подкаталог основного каталога с автономным файлом Karate JAR, чтобы можно было запустить макет, но мне было интересно, есть ли лучший способ ...

Любые отзывы приветствуются, но если они отрицательные, предложите мне альтернативу. Спасибо.


person Alex Mykayak    schedule 07.12.2020    source источник


Ответы (1)


Ответ на ваш второй вопрос здесь: https://stackoverflow.com/a/58339662/143475

На мой взгляд, не существует Right Way ™ для организации ваших макетов и тестируемых приложений. Предложенный вами подход будет работать, я бы использовал параметр --network в Docker, например, если сеть называется mocks, и вам нужно решить и, возможно, указать номер порта, например 8080, вы устанавливаете URL-адреса во втором контейнере как http://mocks:8080

Вы можете почерпнуть некоторые идеи на этой странице в руководстве по распределенному тестированию Karate: https://github.com/intuit/karate/wiki/Distributed-Testing

Обратите внимание, что моки Каратэ разработаны так, чтобы требовать только JRE и фатжара. Это может упростить ситуацию, например, вам может даже не понадобиться Dockerize, просто поставьте java на PATH и укажите на свои *.feature файлы, и все готово. Даже если вы используете код Java, вы можете либо добавить их в CLASSPATH, либо самостоятельно создать фатжар, используя maven-shade.

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

  1. вы можете динамически выбирать порт и передавать его в основную конфигурацию приложения
  2. запуск, остановка и координация двух процессов проще (код Java)
  3. CLASSPATH автоматически позаботится о
  4. если вы станете амбициозным и попытаетесь охватить код в будущем, это может быть проще

Дополнительная литература: https://stackoverflow.com/a/61414022/143475

person Peter Thomas    schedule 08.12.2020
comment
Я не могу понять, почему кто-то говорит, что вам, возможно, не нужно докеризовать что-то ... Основная причина в том, что вам не нужно устанавливать ничего, кроме докера, и просто очень легко интегрировать эти инструменты в CI / CD. - person Sachin Giri; 03.07.2021
comment
@SachinGiri, потому что единственным предварительным условием является JRE (среда выполнения Java), которая во многих случаях (например, AWS) предустановлена ​​и, как можно утверждать, ее проще установить, чем Docker или большинство сред CI / CD. это нормально, если вы не понимаете, другие могут :) - также см. jbang github.com/intuit/ карате # jbang - person Peter Thomas; 03.07.2021