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

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

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

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

Есть ли у кого-нибудь предложения по этому сценарию? Дополнительная информация: я использую liquidbase, panache entity, junity.


unit-testing quarkus junit quarkus-rest-client quarkus-panache
person Willyan    schedule 29.04.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

  1. В зависимости от типа базы данных вы можете использовать h2 в памяти или использовать testcontainers для внешних служб.
  2. Имейте тестовые сценарии запуска для sql для общих данных, вставляйте данные напрямую для небольших тестовых случаев.
  3. Для реальных вызовы API

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

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

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

person Dmytro Chaban    schedule 30.04.2020
comment
Ваш ответ очистил мою голову, потому что я пытался создать модульные тесты, используя логику интеграционных тестов. Я думаю, что эта путаница возникла из-за того, что я использовал rest-assured, и, когда я видел много тестов для Quarkus с его использованием, я подумал, что это лучший подход. Но теперь я создам модульный тест, используя Mockito и rest-assured для интеграционных тестов. Спасибо за вашу помощь. - person Willyan; 30.04.2020