Classic ABAP development relies on the Change and Transport System (CTS) for transporting development objects between systems in the SAP landscape.
This requirement hasn’t changed for the backend part of SAP S/4HANA applications. The core data services (CDS), Business Object Processing Framework (BOPF), ABAP, and OData backend artifacts required for your OData service solely make use of the standard ABAP development lifecycle management. A classic SAP landscape usually consists of a development system (DEV), quality assurance system (QAS), and production system (PROD), as shown below.
The QAS serves as the main code line of our ABAP backend where new features developed in the DEV system(s) are integrated. From a continuous integration (CI) standpoint, you can integrate changes frequently by releasing transport requests in the DEV system on a regular basis (usually daily) can be beneficial. As with SAPUI5 frontend projects, this approach fosters runnable software, encourages customer feedback, and prevents integration hell. Therefore, the classic ABAP system landscape can also be considered as a kind of a CI/CD pipeline where code from developers is integrated in a QAS system before being deployed into production.
Before developers release their transport requests in the DEV system, they should get feedback about the quality of their development via static code checks and ABAP unit tests to catch bugs as early as possible in the pipeline. Subsequently, in the QAS system, automated tests and checks should be periodically run, for instance, every night to detect integration problems and regressions because solely integrating the transports into a main code line is not enough to verify that the software is actually working. Manual testing could be supplemental but should not be required.
If the test and checks executed in the QAS system are all clear, we can transport the new features to the PROD system. To prevent the transport of erroneous objects to the next stage of the pipeline, we might want to establish quality gates (Q gates) at transport releases in the DEV and QAS systems. By automating the testing required in the DEV and QAS systems, you could significantly reduce the time needed for getting features into production and could increase quality by reducing (regression) bugs reaching the PROD system. The main tool that supports the just outlined scenario in the ABAP backend is the ABAP Test Cockpit (ATC).
Quality Checking Using the ABAP Test Cockpit
Based on the Code Inspector, the ATC is SAP’s standard quality assurance infrastructure for all kind of checks and tests. In this section, you’ll get a high-level overview of the best practice setup for an ATC test infrastructure, usually established by a quality manager. Additionally, you’ll learn how to work with ATC checks locally as a developer in a development system to catch bugs at the earliest possible stage of the CI/CD pipeline.
ABAP Test Cockpit Best Practice Infrastructure Setup
The best practice recommendation for ATC quality checking introduces ATC checks at four different levels on the DEV and QAS systems, as shown in the below figure:
Developers continuously run ATC checks from the ABAP development tools in Eclipse when developing in the DEV system.
- The development team checks their development objects continuously using automatic ATC checks in the DEV system.
- As soon as a developer or development team releases a transport, the contained objects are checked using ATC checks, which implements a Q gate between the DEV and QAS systems.
- In the ATC master system (QAS system), the quality manager periodically runs mass quality checks and publishes the results to the ATC satellite DEV system(s) as the active ATC result, which also serves as a Q gate between the QAS and PROD system.
Usually, this test infrastructure is set up by a quality manager who will define the central code line or, in ABAP terms, the consolidation or quality system, where mass regression tests should happen. The QAS can be supplied from several different DEV systems, so continuously checking for integration problems and regressions—for instance, method signature changes where callers weren’t yet updated, missing dependencies present in other not-yet-released transports, or side effects introduced with new features that break older functionality—is important.
When setting up the test infrastructure for an SAP landscape, the quality manager will first define the ATC master system where central ATC quality checking will take place on a regular basis, for instance, daily, as mentioned earlier, usually the QAS system of the landscape. The development or correction systems (DEV) that transport new ABAP development objects, such as CDS views, ABAP classes, or SAP Gateway artifacts, to the QAS systems are the ATC satellite systems.
In the second step, the ATC master system and the ATC satellite systems must be connected via trusted RFC connections so that the ATC master system can distribute the central ATC results to the ATC satellite systems.
In the third step, the quality manager will set up and schedule the ATC check locally on the ATC master system using Transaction ATC, including whether the ATC checks will also be executed on transport release in the satellite systems. What checks are concretely executed must be previously defined in the form of a global SCI variant using Transaction SCI. static code checks can be included as can dynamic tests in the form of ABAP unit tests.
Finally, each development ATC satellite system can download the ATC configuration settings defined in the ATC master system, for instance, the SCI check variant using Transaction ATC. As a result, developers can run the same ATC checks locally as the quality manager does in the central consolidation system.
Dealing with ABAP Test Cockpit Checks Locally in a Development System
As a developer in the DEV system, you can execute a local (default) ATC check variant for a currently opened development object in the ABAP development tools in Eclipse using the shortcut (Ctrl)+(Shift)+(F2) or by right-clicking on the development object in the Project Explorer view and selecting Run As > ABAP Test Cockpit. The ATC work list will then be displayed in the ATC Problems view, as shown below. If the view isn’t visible, navigate to Window > Show View > Other > ATC Problems and select the view.
To run a different check variant, for instance, a locally defined stricter check variant than the default check variant from the ATC master system, you can open the context menu of a development object in the Project Explorer and choose Run As > ABAP Test Cockpit With.
To display the ATC check result distributed by a central ATC master system, you must open the ATC Result Browser view, as shown below. You can do this by choosing Window > Show View > Other > ATC Result Browser.
You can also create a feed for the currently active ATC result and receive notification messages for findings by first displaying the Feed Reader view (Window > Show View > Other > Feed Reader) and then choosing Add Feed Query > ATC Findings from the context menu of the system. The New Feed Query dialog box will open, where you’ll then configure the exact ATC results you want to receive notifications for, for instance, ATC errors for your objects with priority 1 or 2, as shown here:
Learn about ABAP Test Cockpit administration here.
Scheduling ABAP Unit Tests Using the ABAP Unit Runner
Lightweight regression testing in a development or quality system can also be done using the ABAP Unit Runner (program RS_AUCV_RUNNER). Compared to setting up an ATC infrastructure, setting up a periodically running ABAP Unit Runner job is simple and can be achieved without involving the SAP Basis team. Therefore, using the ABAP Unit Runner could be a first step to continuous regression and integration testing. With the ABAP Unit Runner, you can run unit tests by packages (1) and notify certain people (usually the quality manager or developer) of test results always or only when errors arise (2), as shown below.
To periodically schedule unit tests as a background job, first you must save the previously selected packages and entered email recipients as a variant of the report by clicking the Save button or by choosing Menu > Go To > Variants > Save as Variant. For our example, we’ll call our variant Z_UNIT_TESTS.
To define a background job for our unit test variant, we must use Transaction SM36, as shown below. First, we’ll provide a name for our job (1), then specify what our job will run by clicking the Step (button 2), and finally specify when our job should run via the Start condition (button 3).
The next figure shows the configuration we entered inside the Create Step 1 dialog: the ABAP Unit Runner report RS_AUCV_RUNNER and our Z_UNIT_TESTS variant containing our packages and email recipients.
In the Start Time dialog, shown in the final figure, opened by the Start Condition button, you must enter the start date and time for your job (1) and the Period Values (3), for instance, Daily if we want the job to run every day at the time specified in the Scheduled Start Time field. The Period Values dialog box can be opened by clicking the Period Values (button 2). Don’t forget to save everything.
To display and check the service, use Transaction SM37.
Conclusion
In this post, we introduced you to the ABAP Test Cockpit infrastructure as a best practice setup for the ABAP backend, discussed how to carry out ATC checks locally as a developer in the development system, and examined using the ABAP Unit Runner as a lightweight alternative for running unit tests.
Comments