I am trying to write unit tests for a custom class, let's call it, OutboundDeliveryUpdater which has a dependency on com.sap.cloud.sdk.s4hana.datamodel.odata.namespaces.outbounddeliveryv2.batch.OutboundDeliveryV2ServiceBatch (it is a class field). The requirement is to update multiple Outbound Delivery Items on the S4 system. The method in OutboundDeliveryUpdater which performs the update looks like this (omitting exception handling for brevity):
OutboundDeliveryV2ServiceBatchChangeSet changeSet = outboundDeliveryService.beginChangeSet();
itemsForUpdation.forEach(changeSet::updateOutbDeliveryItem);
changeSet.endChangeSet();
BatchResponse batchResponse = outboundDeliveryService.execute(destination);
boolean isUpdateSuccessful batchResponse.get(0).isSuccess();
Now the problem is that while writing unit test for the above code, following things have to be mocked:
outboundDeliveryService.beginChangeSet()andoutboundDeliveryService.execute(destination)destination, which is an instance of HttpDestinationchangeSet.updateOutbDeliveryItem()batchResponse.get()
This makes the unit test very complicated. We have to mock a real dependency (outboundDeliveryService) and the objects that are returned by the methods which are executed on that dependency (changeSet, batchResponse). This seems to be a classic violation of Law of Demeter and the code demonstrates the flaw of digging into collaborators and this is the reason why it is becoming hard to write unit tests for this code.
Is there a better way of writing:
- The unit tests for this code to prevent all this complexity?
- If not then is there a better way of designing
OutboundDeliveryUpdaterso that the issue is solved? For e.g.OutboundDeliveryUpdatercan have a dependency on a new class, let's say,SomeServicewhich acts as a facade and hides the complexity ofOutboundDeliveryV2ServiceBatchChangeSet. But this again will shift the complexity of testing fromOutboundDeliveryUpdater's unit test toSomeService's test.
Aucun commentaire:
Enregistrer un commentaire