Step 19 with S/4HANA Cloud SDK: The following steps will explain how you can mock SAP S/4HANA-specific dependencies inside your tests using the SAP S/4HANA Cloud SDK.

Note: This post is part of a series. For a complete overview visit the SAP S/4HANA Cloud SDK Overview.

Goal of this blog post

This blog post introduces to you the mocking capabilities of the SAP S/4HANA Cloud SDK in more detail. After this blog you will be able to understand

• What mocking is and why it is a useful tool and programming capability.
• How you can mock the access to SAP S/4HANA systems enabling you to test and develop your S/4HANA extension without an S/4HANA system.

Prerequisites

In order to successfully go through this tutorial you have to complete the tutorial at least until:

• Step 4 with SAP S/4HANA Cloud SDK: Calling an OData Service

As we will also refer to mocking of resilient S/4HANA calls, it is beneficial to also be familiar with resilient programming as outlined in:

• Step 5 with SAP S/4HANA Cloud SDK: Resilience with Hystrix.

In addition, we will use the virtual data model for OData as introduced in

• Step 10 with SAP S/4HANA Cloud SDK: Virtual Data Model for OData.

In addition, complete mocking of S/4HANA APIs only works stable as of S/4HANA Cloud SDK version 1.5.0. Therefore, please make sure, your SDK Bill of Material is updated accordingly like shown below:

   com.sap.cloud.s4hana sdk-bom 1.5.0 pom import    

Mocking Theory

Motivation

In our previous tutorials and deep dives such as

• Step 4 with SAP S/4HANA Cloud SDK: Calling an OData Service
• Step 10 with SAP S/4HANA Cloud SDK: Virtual Data Model for OData
• Step 13 with SAP S/4HANA Cloud SDK: Automated Testing
• Step 14 with SAP S/4HANA Cloud SDK: Continuous integration and delivery
• Deep Dive 3 with S/4HANA Cloud SDK: Cloud Platform Abstractions

we have been mostly using so-called integration tests to test the functionality of our application in conjunction with the SAP S/4HANA system. While this provides a very convenient way to test the overall functionality from SCP backend to S/4HANA backend, having too many of them leads to brittle and hard to maintain test suites.

First, you actually require a SAP S/4HANA system which is configured and up-and-running to provide the APIs you require. This means you have to provide and maintain a corresponding S/4HANA system during development to run your tests. This can be expensive and potentially error-prone leading to longer feedback cycles for the software engineering team. In addition, sometimes you may require updates to the S/4HANA backend system which are not yet transported into the system instance you are using for running your integration tests. This slows down feedback cycles even further and potentially stalls effective progress with your SCP extension leading to frustration of the software development team.

Secondly, in order to fulfill comprehensive testing, code coverage and other quality requirements it is all too tempting providing everything as integration tests. However, integration tests are slow, in particular when you have many of them. They require to bootstrap a full or embedded container (e.g., TomEE as provided with the S/4HANA Cloud SDK) as well as a complete, functional connection to S/4HANA doing real RESTful calls over the wire. Hence, the more your application grows, the slower your test suite eventually becomes. This has a negative impact on your development team performance, is frustrating and may require additional significant investments into vertical or horizontal scaling.

Therefore, also as the testing pyramid below suggests, you shall have much more unit tests in your codebase than integration tests. Unit tests are self-contained and only test a small portion (e.g., class) of the codebase within one test. Therefore, issues can be detected faster and unit tests run much faster (usually one to two orders of magnitude) than integration tests. Additionally, unit tests force application developers to write more testable application code and apply separation of concerns more thoroughly which usually leads to better maintainable and understandable code.

However, this yields the question how you can test a small portion of your codebase, if it is directly or indirectly dependent on some integration point with SAP S/4HANA, a real database or simply another Java object that is not part of the testing scope.

The answer is simple: Use Mocking.

What is Mocking

Mocking in general refers to the idea of providing test doubles instead of the real implementation during a test. Like in latest movies, a double of an actress comes into play when particular risky scenes such as stunts are recorded which cannot be done by the Oscar-nominated movie star. With testing, we are not so much concerned about the well-being of the double but rather its runtime costs and state which might be hard to provide or imitate during testing.

When writing tests we are oftentimes faced with the situation that it is too cumbersome or sometimes even impossible to instantiate the entire program or produce a certain state of the program. In this case, we can provide test doubles that act on behalf of the real implementation. Test doubles comes in different forms such as mocks, stubs, spies, fake, or dummy objects. We leave the subtle differences to the plenty of related work such as Martin Fowler’s – Mocks Aren’t Stubs or lengthy Stackoverflow debates.

In the following text, we will mostly refer to mock or stub objects when mocking behavior and state respectively.

Mocking the Business Partner API

In the following tutorial, we will introduce three basic mocking principles that should empower you with all the tools and requirements you need. We will go over the following important aspects:

• Mocking the happy path generically: Return successfully all business partners without an S/4HANA system.
• Mocking the failure path: Return an error thrown by the business partner API without an S/4HANA system.

Mocking the happy path

Let’s start with a very simple example of a GetBusinessPartnerCommand which retrieves all business partners’ first and last names that are customers. If you did all the tutorials at least until Step 5 with SAP S/4HANA Cloud SDK: Resilience with Hystrix plus Step 10 with SAP S/4HANA Cloud SDK: Virtual Data Model for OData, the code should be very familiar to you.

The file needs to be put under your /application/src/main/java directory.

public class GetBusinessPartnerCommand extends ErpCommand<List> { private BusinessPartnerService businessPartnerService; public GetBusinessPartnerCommand(ErpConfigContext erpConfigContext, BusinessPartnerService businessPartnerService) { super(GetBusinessPartnerCommand.class, erpConfigContext); this.businessPartnerService = businessPartnerService; } @Override protected List run() { try { return businessPartnerService.getAllBusinessPartner() .filter(BusinessPartner.IS_NATURAL_PERSON.eq("X")) .select(BusinessPartner.FIRST_NAME, BusinessPartner.LAST_NAME ) .execute(getConfigContext()); } catch (final ODataException e) { throw new HystrixBadRequestException(e.getMessage(), e); } } }

Unlike previous tutorials, we do not want to test this now against a real S/4HANA system but just by a locally running test.

For this, we put the following test file called GetBusinessPartnerMockedTest under /unit-tests/src/test/java.

public class GetBusinessPartnerMockedTest { private static final MockUtil mockUtil = new MockUtil(); private static BusinessPartner alice; private static BusinessPartner bob; @BeforeClass public static void beforeClass() throws Exception { mockUtil.mockDefaults(); mockUtil.mockDestination("ErpQueryEndpoint", URI.create("")); alice = new BusinessPartner(); alice.setFirstName("Alice"); bob = new BusinessPartner(); bob.setFirstName("Bob"); } @Test public void testGetAnyBusinessPartner() throws Exception { final BusinessPartnerService service = Mockito.mock(BusinessPartnerService.class, RETURNS_DEEP_STUBS); when(service.getAllBusinessPartner() .filter(any(ExpressionFluentHelper.class)) .select(any(EntityField.class)) .execute(any(ErpConfigContext.class))) .thenReturn(Lists.newArrayList(alice, bob)); final List businessPartnerList = new GetBusinessPartnerCommand(new ErpConfigContext(), service).execute(); assertEquals(2, businessPartnerList.size()); assertEquals("Alice", businessPartnerList.get(0).getFirstName()); assertEquals("Bob", businessPartnerList.get(1).getFirstName()); } }

You can try it out by right-clicking on your test class and select “Run As Unit Test” or execute mvn clean test on your root project.

If you use an IDE you should see the test passing in very quick time.

Also, in any IDE we can look at the code coverage that this test provides. So far, the test accounts for 77% of all lines of code (we will achieve 100% in this tutorial).

Mocking the failure case

Mocking is also a very powerful technique to test hard-to-reach code such as certain failure cases.

In our example, we can run into situations where the OData call to the business partner API may fail during runtime (due to failing network, wrong authorizations, etc.). This is unfortunate and we cannot do anything about failing OData calls at design-time, but we must test whether our code behaves correctly in such failure situations and leaves the application in an expected, consistent state.

Fortunately, we can also mock such failure cases by throwing a dummy ODataException and expect a HystrixBadRequestException as the test result (in case you have not stumbled over the HystrixBadRequestException yet, we just mention that this is the standard contract of Hystrix to signal an expected exception that must not trigger any resilience functionality such as circuit breakers).

@Test(expected = HystrixBadRequestException.class) public void testGetBusinessPartnerFailure() throws Exception { final BusinessPartnerService service = Mockito.mock(BusinessPartnerService.class, RETURNS_DEEP_STUBS); when(service.getAllBusinessPartner() .filter(any(ExpressionFluentHelper.class)) .select(any(EntityField.class)) .execute(any(ErpConfigContext.class))) .thenThrow(new ODataException(ODataExceptionType.METADATA_FETCH_FAILED, "Something went wrong", null)); new GetBusinessPartnerCommand(new ErpConfigContext(), service).execute(); }

When we run all our three test cases together, we finally end up with a 100% tested codebase, although we do not have used any real S/4HANA system.

Recommendation and Hints

The mocking facilities of the SAP S/4HANA Cloud SDK are based on the open source framework Mockito. Therefore, we recommend you to study the official documentation for more options and capabilities.

1. One of the additional possibilities is to use the @Mock annotations for providing the mocks in the tests which lead to less code and more readable tests. For example, we can mock the business partner service as well as our two business partner, Alice and Bob and can leave out the mocking per test method. Please note that the JUnit test has to be annotated with @RunWith(MockitoJUnitRunner.Silent.class).The full running code for this is here:

   @RunWith(MockitoJUnitRunner.Silent.class) public class GetBusinessPartnerMockedTest { private static final MockUtil mockUtil = new MockUtil(); @Mock(answer = Answers.RETURNS_DEEP_STUBS) private BusinessPartnerService service; @Mock private BusinessPartner alice; @Mock private BusinessPartner bob; @Before public void before() { mockUtil.mockDefaults(); mockUtil.mockDestination("ErpQueryEndpoint", URI.create("")); when(alice.getFirstName()).thenReturn("Alice"); when(bob.getFirstName()).thenReturn("Bob"); } @Test public void testGetAnyBusinessPartner() throws Exception { when(service.getAllBusinessPartner() .filter(any(ExpressionFluentHelper.class)) .select(any(EntityField.class)) .execute(any(ErpConfigContext.class))) .thenReturn(Lists.newArrayList(alice, bob)); final List businessPartnerList = new GetBusinessPartnerCommand(new ErpConfigContext(), service).execute(); assertEquals(2, businessPartnerList.size()); assertEquals("Alice", businessPartnerList.get(0).getFirstName()); assertEquals("Bob", businessPartnerList.get(1).getFirstName()); } @Test(expected = HystrixBadRequestException.class) public void testGetBusinessPartnerFailure() throws Exception { when(service.getAllBusinessPartner() .filter(any(ExpressionFluentHelper.class)) .select(any(EntityField.class)) .execute(any(ErpConfigContext.class))) .thenThrow(new ODataException(ODataExceptionType.METADATA_FETCH_FAILED, "Something went wrong", null)); new GetBusinessPartnerCommand(new ErpConfigContext(), service).execute(); } }

2. The test itself can be still refactored to avoid duplicate code. For example, certain mock conditions, e.g., any business partner API call could be externalized into a separate method for better reuse and readability.
3. The mocking facility also works greatly with the S/4HANA Cloud SDK Continuous Delivery Pipeline as introduced in Step 14 with SAP S/4HANA Cloud SDK: Continuous integration and delivery. This helps to achieve higher code coverage and higher qualities which are checked by the pipeline.

Unit tests are not the ultimate answer to everything. They do not replace integration or system tests which test the emergent behavior of the entire system. This raises the question when to provide a unit and when to provide an integration test.

As explained above, you should give favor to unit tests whenever possible to ensure that your test suite executes fast. However, integration tests are a nice way to test the overall business semantics of your application, in particular, when multiple, complex interactions should be tested under “more real” conditions (“more real” means that no matter how much effort you put into testing, you will never get as real as the productive system, in particular, in highly distributed cloud applications).

In addition, for mocking the S/4HANA APIs as explained above, you have to have a certain understanding of how the APIs behave, otherwise it would be hard to assert their behaviors. When you do not have any S/4HANA system yet, we recommend you to use the API Business Hub Sandbox to understand the behavior to make better mocking assumptions.

Summary

In this tutorial, we have shown how you can leverage the S/4HANA Cloud SDK to mock S/4HANA calls during development to create fast running unit tests which require a data dependency to SAP S/4HANA. This way, you can start building and testing your S/4HANA extension on SCP already without having an SAP S/4HANA system. When you utilize an S/4HANA system for integration tests, you can make sure that you have much more unit tests than integration tests to maintain a fast, non-brittle test suite.

Questions?

Reach out to us on Stackoverflow via our s4sdk tag. We actively monitor this tag in our core engineering teams.

Alternatively, we are happy to receive your comments to this blog below.