Как выполнить модульное тестирование класса, имеющего зависимость от OutboundDeliveryV2ServiceBatch?

Question

Использование java SAP Cloud SDK

Я пытаюсь написать модульные тесты для пользовательского класса, назовем его OutboundDeliveryUpdater, который зависит от com.sap.cloud.sdk.s4hana.datamodel.odata.namespaces.outbounddeliveryv2.batch.OutboundDeliveryV2ServiceBatch ( это поле класса). Требуется обновить несколько элементов исходящей доставки в системе S4. Метод в OutboundDeliveryUpdater, который выполняет обновление, выглядит следующим образом (для краткости опущена обработка исключений):

OutboundDeliveryV2ServiceBatchChangeSet changeSet = outboundDeliveryService.beginChangeSet();

itemsForUpdation.forEach(changeSet::updateOutbDeliveryItem);

changeSet.endChangeSet();

BatchResponse batchResponse = outboundDeliveryService.execute(destination);

boolean isUpdateSuccessful = batchResponse.get(0).isSuccess();

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

1. outboundDeliveryService.beginChangeSet() и outboundDeliveryService.execute(destination)
2. destination, который является экземпляром HttpDestination
3. changeSet.updateOutbDeliveryItem()
4. batchResponse.get()

Это делает модульное тестирование очень сложным. Мы должны смоделировать реальную зависимость (outboundDeliveryService) и объекты, возвращаемые методами, которые выполняются на этой зависимости (changeSet, batchResponse). Кажется, это классическое c нарушение Закона Деметры , и код демонстрирует недостаток копания в соавторах , и именно поэтому становится трудно писать модульные тесты для этого кода.

Есть ли лучший способ написания:

1. Модульные тесты для этого кода, чтобы предотвратить всю эту сложность?
2. Если нет, то есть ли лучший способ проектирования OutboundDeliveryUpdater, чтобы проблема была решена? Например, OutboundDeliveryUpdater может зависеть от нового класса, скажем, SomeService, который действует как фасад и скрывает сложность OutboundDeliveryV2ServiceBatchChangeSet. Но это снова сместит сложность тестирования с модульного теста OutboundDeliveryUpdater на тест SomeService.

Answer 1

Вы смотрели на Мокито ? Это позволяет использовать «Глубокое копирование» согласно этому примеру .

Альтернатива для макетирования всех зависимостей этого класса для целей изолированного модульного теста: использовать WireMock .

Следуя этому подходу, вы запустили крошечный HTTP-сервер во время выполнения теста, который в основном копирует систему SAP S / 4HANA. Кроме того, вы должны указать WireMock, какой ответ OData должен отправлять на какой запрос OData.

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

В конце концов, это зависит от того, чего вы хотите достичь.