如何对依赖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）。这似乎是对Law of Demeter的经典违反，并且该代码演示了digging into collaborators的缺陷，这就是为什么很难为此代码编写单元测试的原因。

是否有更好的书写方式：

1. 单元测试此代码以防止所有这种复杂性？
2. 如果没有，那么有没有更好的方法来设计OutboundDeliveryUpdater，以便解决问题？例如OutboundDeliveryUpdater可以依赖于新类，比方说，SomeService充当外观并隐藏OutboundDeliveryV2ServiceBatchChangeSet的复杂性。但这又会将测试的复杂性从OutboundDeliveryUpdater的单元测试转移到SomeService的测试。

Answer 1

您看过Mockito吗？它允许根据this example使用“深度模拟”。

An alternative出于隔离单元测试的目的，模拟此类的所有依赖项是使用WireMock。

按照这种方法，您将在测试执行期间启动一个微型HTTP服务器，该服务器基本上可以模拟SAP S / 4HANA系统。此外，您将告诉WireMock应该在哪个OData请求上发送哪个OData响应。

请注意，这种方法并未为您的自定义类提供隔离的单元测试概念，而是使您能够测试all涉及的Java类的集成。

最后，取决于您要实现的目标。