Модульное тестирование с участием БД (Вставить / Обновить / Выбрать)

Question

Будем рады узнать лучшие практики в этой области и контексте.

Два сценария ios

1. У меня есть компонент, написанный на Java & Spring, где я нахожусь получение некоторых данных, преобразование их в другой формат, который включает в себя основную бизнес-логику c и вставку / обновление базы данных Cassandra.
2. Другой компонент java считывает данные из этой БД и запускает бизнес-логи c на этом и позаботиться о некоторых других функциях.

Теперь, когда я пишу примеры модульных тестов, я могу подумать о следующих двух подходах высокого уровня

1. Я могу использовать Mockito или аналогичный и смоделируйте объект DAO, чтобы я на самом деле не вызывал DB при выполнении операций get и save над объектом DAO.
2. На самом деле я не могу смутить и позволить подключиться к БД.
3. Мы подключаемся к БД только во время создания снимка (для нескольких тестовых случаев)

Однако -

Для (1) - На самом деле мы не проверяем, правильно ли хранятся / обновляются данные. Для (2) - Это не должно быть хорошей идеей, чтобы делать это в единицах / регрессии, так как мы не хотим подключаться к БД каждый раз, когда выполняем установку или сборку mvn. Для (3) - Это звучит как лучший вариант, если это выполнимо.

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

Answer 1

Ваш сценарий ios довольно абстрактен, поэтому ответ таков:

Сценарий тестирования ios, который вы описываете, кажется, представляет собой смесь проблем модульного и интеграционного тестирования. В модульном тестировании вы хотели бы тщательно протестировать бизнес-логику c (вычисления, но в идеале не взаимодействовать с другими компонентами) с целью поиска ошибок в вычислительных частях. Зависимости от других компонентов (например, БД) вызывают беспокойство. Однако в интеграционном тестировании вы ищете ошибки во взаимодействии между различными компонентами.

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

Второй тип функций / методов, которые вы получаете после повторного дизайн будет доминировать функции взаимодействия. В идеале функции с доминированием взаимодействия не имеют вычислительного кода, а содержат только взаимодействия с другими компонентами. Тогда для этих функций модульное тестирование не имеет смысла, поскольку единственные ошибки, которые может содержать этот тип кода, это ошибки, такие как вызов функций (или выполнение операций с БД) в неправильном порядке, вызов неправильной функции (или операции с БД), передача аргументов в неправильном порядке, несовместимых аргументов, получение неожиданных данных и т. д. c., и все эти ошибки не могут быть найдены при модульном тестировании, но при интеграционном тестировании.