Unit tests serve several purposes. The most obvious is that they must make it possible to test the underlying business to ensure the correct behavior of the source code. But they also allow you to define the use of the API using simple examples. They play both the roles : quality control and documentation for development team.

Furthermore, they can save time for developers to test their implementation without needing to start the entire platform.

Ideally, all classes in service layer should have their own unit test respecting these objectives: control change and method/service documentation.

By default, SAP Commerce suite offers many unit test examples that can be run with the following command

ant unittests -Dtestclasses.packages="de.hybris.*"
-Dtestclasses.annotations="unittest,integrationtest,performancetest"

And official documentation is rich on this topic

• SAP Commerce: Writing and Executing Tests
• Commerce 123 : Unit Tests
• Commerce 123: Integration Tests
• SAP Commerce: Customizing Test Executions

It can be interesting to include these OOTB tests in the deployment chain in order to measure the distance from OOTB feature after each custom release. Knowing that good practice in operating a software package is to stick as closely as possible to standard functionalities.

Obviously, it is not necessary (or even recommended) to maintain these tests. It is more judicious to study future customizations in order to minimize regression on these tests, as far as possible.

Unit tests are part of a more global testing strategy, including non-regression, smoke, and performance tests. Knowing this, it is appropriate to adapt the coverage of unit tests according to the coverage of other tests that will be executed further downstream. Indeed, it is not necessary to try to test all use cases during unit tests.

For example, If we have end-to-end non-regression tests executed after the UTs, there is no need to write UTs for the Controller layer. Indeed, these tests may be complex to maintain and will be in competition with non-regression tests.

Simple Unit Test

ant unittests -Dtestclasses.annotations="unittest"

We should see unit tests as technical tests of the correct use of the APIs of the different layers: Populator, Facade, Service, and DAO. And from a functional point of view, we should validate the basic business logic such as promotion calculation, data transformation, price calculation and so on.

A good right strategy is to focus implementation effort on Service layer where business logic can clearly be validated. In other words, where we have simple case with high feature validation coverage.

When unit test code coverage is too low, best approach is to include in next Sprint (Agile Methodology) a room for unit test implementation. Each bug fix, performance improvement and new feature should be an opportunity to increase this code coverage on the current Service layer refactoring.

Integration Unit Test

ant unittests -Dtestclasses.annotations="integrationtest"

Integration UTs (@IntegrationTest) are often more relevant when testing Facade and DAO classes.

There are two possible strategies for handling dataset: Sample Data or Direct Impex Injection

Sample Data

We can use the dataset provided during platform initialization using the following command to create the Junit tenant. This dataset is called Sample data. And with this dataset, we should be able to get ready to use solution with all type of content : customer, product, page, CMS component, and so on.

ant initialize -Dtenant=junit

ant yunitinit

Be aware that Sample data is a prerequisite for efficient DevOps in SAP Commerce Cloud. 

This following guide can help you to setup correctly your sample data : https://blogs.sap.com/2023/11/09/strategies-for-loading-data-in-sap-commerce-cloud/

Direct Impex injection

And we can use specific dataset to each UT. An interesting and simple example in SAP Commerce is the DefaultSetupSyncJobServiceTest class which uses the impex testSystemSetup.impex

@Before
public void setUp() throws Exception {
      [...]
  importCsv("/commerceservices/test/testSystemSetup.impex", "utf8");
}

This second strategy can complete dataset provided by Sample data.

Locally

Each developer should run his own unit test locally before to commit their change in main git branch. For that, they simply has to init their junit tenant (seprated local database that contain Sample data).

ant initialize -Dtenant=junit

or

ant yunitinit

Then, they should execute only unit tests that corresponding to their change by filtering on package class and annotation.

ant unittests -Dtestclasses.packages="com.customer.service.*"
-Dtestclasses.annotations="unittest,integrationtest,performancetest"

At the end of this execution, they can consult unit tests result on : hybris/log/junit/index.html

During Cloud Build

Each new release build is an opportunity to measure global code quality progression. During this build, we can execute all relevants unit tests that includes core product plus custom code.

This setting is stored into core-customize/manifest.json. In below an example, that should help you.

"tests": {
        "extensions": [
            "kiwi",
            "tiger"
        ],
        "annotations": [
            "UnitTests",
            "IntegrationTests"
        ],
        "packages": [
            "de.hybris.*",
            "com.acme.*"
        ]
    }

Idea is to see how many core product tests are still working and to have global view on all custom unit tests result.

SAP Commerce Cloud won’t block a build because one or many test failures. Each failure should be analysis to understand if it is impacting the release itself or because the test is not relevant anymore.

External orchestrator as Jenkins can automate build and unit tests verification by using SAP Commerce API.

Unit test result can be consulted in build log.

Unit test is essential for many reasons: It helps to increase code quality, it gives a quick view how fare your solution is from standard, it provides API/Service documentation by providing example, it accelerates code implementation by providing easy way to test small piece code with no need to get a full dataset solution from production.

When code coverage has been identified as low by SAP Expert Services, Partner/Customer IT division should take quickly countermeasure to avoid technical debt accumulation.

This accumulation can lead to a situation where the solution is so tailored to specific needs that it becomes inflexible and resistant to change, necessitating a complete platform replacement.

Fortunately Customer/Partner can request SAP Expert Services where this best practice application can be audited in your solution: Code Review. And we can even help you to implement unit test fondation for your project.