Каков наилучший подход для выполнения модульных тестов конечной точки в Quarkus? - PullRequest
Новая
       115

Каков наилучший подход для выполнения модульных тестов конечной точки в Quarkus?

1 голос
/ 29 апреля 2020

У меня есть некоторые сомнения относительно лучшего подхода для выполнения юнит-тестов в Quarkus.

Один из вариантов - использование mocks, но у меня есть ощущение, что, используя mocks, я просто "радуюсь" плагинами тестового покрытия, но на самом деле я ничего не тестирую с этим подходом.

Другой вариант - использование реальной базы данных, например, встроенной базы данных H2, но для этого мне нужно расположить модульный тест по порядку (Вставить, Получить, Обновить, Удалить), иногда мне понадобится вставленный идентификатор из другого теста для выполнения операция удаления, например. Есть некоторые сложные объекты, которые создают некоторые трудности для вставки или удаления. Таким образом, при таком подходе я потеряю концепцию модульного теста, потому что потеряю взаимозависимость тестов.

Есть ли у кого-нибудь предложения по этому сценарию? Дополнительная информация: я использую LiquidBase, Panache Entity, Junity.

1 Ответ

1 голос
/ 30 апреля 2020

Похоже, вы ищете интеграционные тесты. Я бы, вероятно, go со следующими параметрами:

  1. В зависимости от типа базы данных, вы можете либо go с h2 в памяти, либо использовать testcontainers для внешних служб.
  2. Иметь тестовые сценарии запуска для sql для общих данных, вставлять данные непосредственно для небольших тестовых случаев.
  3. Использовать такие инструменты, как http://rest-assured.io/ (обычно включается в начальные setup) для выполнения реальных вызовов API

Если вам действительно нужны юнит-тесты, в этом случае 90% времени вам не нужно иметь базу данных для тестирования функциональности. Из-за развязки у вас, вероятно, есть контроллеры (ресурсы) отдельно от сервисов. Так что в случае модульных тестов я бы, вероятно, go с:

  1. Как указано выше, отделить logi c от сетевого уровня, так что любая обработка запроса и упаковка вывода для удовлетворения клиентов не будут слоя logi c. Разделите сам logi c на более мелкие куски, если это возможно, это устранит вашу основную озабоченность сложными данными
  2. Для любых зависимых зависимостей либо переопределите их с тестовыми бобами , либо издеваться над ними, используя Mockito . Это особенно важно для постоянства, вам нужно смоделировать или подделать любое соединение с базой данных, вам не нужно проверять эту часть, потому что она обычно обрабатывается библиотеками.
  3. Вы можете читать JSON объектов из файлов для действительно сложные сущности
  4. Если вам действительно нужно иметь постоянство, посмотрите на самый первый пункт этого ответа.

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

...