ABAP Unit - Automation
When do objects break during development and what side effects can adjustments have? In this article we take a closer look at the topic.
Table of contents
Let's take a look at automation in the ABAP unit area and what advantages you can get from it in your daily work.
Introduction
Unit tests are widely used in software development. The primary aim is to equip the various components in the system with tests in order to be able to test them individually and automatically. Every object should therefore be written as testable as possible and the tests should be as robust as possible in order not to be dependent on system data and to avoid frequent adjustments to the tests.
The tests make it possible to make adjustments to the object and validate whether all defined tests still work. If the tests are available, the components are tested manually afterwards. With every change in the future, we have the opportunity to carry out all tests in seconds without knowing them ourselves.
Side effects
A high coverage of the objects in the system creates a large safety net in order to also validate side effects of adjustments on other developments. So let's say we change a core component that is used in many places. Such a component has its own unit tests that, when executed, validate that the class still behaves as our test cases were defined.
Our adjustments now have an impact on other objects that also use the component. However, it's difficult for us to get an overview of it and we don't always want to test all the components we use.
There are typically two error situations here:
- Errors in the compiler - Even when we call the object, we get error messages because interfaces in public methods have changed or methods are completely missing.
- Error while executing - Unexpected values are being returned from the component causing errors in our application.
We want to identify such side effects very early, if possible during development, in order to be able to react to them and avoid downtimes in productive operations.
ABAP Test Cockpit
In the ABAP Test Cockpit (ATC) you can also configure that the unit tests are executed when the ATC test is running. There are options here to start the test manually using CTRL + SHIFT + F2, to check several objects in the Project Explorer or to configure the ATC so that the unit tests are also started when the task is released.
When configuring the variant, you can make settings as to which unit tests are carried out in which classification in order to avoid critical tests and not have long-running problems with transport release.
{
"checkName": "ABAP_UNIT",
"parameters": [
{
"name": "MaximumRiskLevel",
"value": "11"
},
{
"name": "MaximumRuntimeCategory",
"value": "12"
},
{
"name": "RuntimeRestriction",
"value": "2"
},
{
"name": "DurationLong",
"value": "3600"
},
{
"name": "DurationMedium",
"value": "300"
},
{
"name": "DurationShort",
"value": "60"
}
]
}
On-Premise / Private Cloud
In the classic R/3 or S/4 system there is the report RS_AUCV_RUNNER, which can be scheduled as a regular job and contains additional setting options to separate responsibilities and tests.
RS_AUCV_RUNNER
So let's call up the report and check the points of the configuration or selection screen.
The first part is mainly for configuring the objects to be executed:
- Selection - selection of the selection by package or program, accordingly other restrictions are available in the area below.
- Restriction objects - The restriction depends on the previously selected selection. In this case, the restriction by package was chosen. We can use this to specify the packages to be tested in this run. Likewise, whether sub-packages are used and whether certain objects are not tested.
- Risk and duration - Here you can define which unit tests should be executed. This depends on the test class classification made by the developer. If only quick and harmless tests are to be carried out, this can be defined. It is also possible to start tests that make changes or adjust customization.
The following setting options are available:
- Display - sending the result as an email or displaying the data as ALV.
- Sending options - Different recipients or distribution lists can be specified and it can also be defined whether an email should only be sent in the event of an error.
- Content - The content and level of detail of the email can be defined here. If the tested objects are to be listed, the URLs to the ABAP Development Tools should be integrated.
The level of detail can be used to set the information that the user should receive in the email. There is a distinction according to:
- No detailed information - An overview of the system and the test time is provided. This is followed by a list of the test statistics and then the failed tests.
- Basic Information - Contains the information from above, plus further details about the canceled test classes and tests.
- Full Information - Contains the information from above, plus all tests and test classes executed. This means you can decide for yourself whether you want to see the classes that were actually completed successfully.
ABAP Environment / Public Cloud
There is currently no solution to automatically start all tests in the system and check for completeness. However, we think that this feature will also be available on the system in the near future, whether as a class or as a scheduled job.
Conclusion
Automated execution of unit tests can be implemented quickly and gives you the assurance every day that the system still works as it was defined. This requires some preliminary work, but it helps in everyday life and for new colleagues to understand the system and expand the software properly.
Further information:
