Testing and Debugging ABAP SAP BASIS

This section introduces some of the most important utilities within the ABAP Workbench to test and debug ABAP programs. ABAP is a powerful programming language for developing sophisticated business applications, and for the very same reason it is important to be able to test those developments and avoid errors during runtime that might have not been initially foreseen, such as unexpected messages, incorrect return codes, performance errors, and others.

A single tool would not be enough to detect all types of situations that could happen during the development of a SAP application. The ABAP Debugger can be used to see the content of an internal table at runtime, but it is not the proper tool to detect performance problems. SAP, within the Web Application Server, provides a collection of tools that can be used to perform code verification in a static manner, as well as more detailed analyses of system events, analysis of processes with errors, setup of traces at runtime, as well as perform debugging at runtime.

As a starting point, we will assume that the programs being analyzed are free of syntactical errors, and therefore we can activate and run them. For the most part, if there are initial syntax errors, the programs cannot even be activated. However, even with these premises, we cannot guarantee that there will be no errors at runtime. The main transactions and tools within the ABAP Workbench that can be used to debug and test ABAP programs are as follows:

  • ABAP Debugger
  • Runtime analysis
  • Performance Trace
  • Extended program check
  • Code Inspector
  • ABAP Unit
  • eCATTs
  • Coverage Analyzer

The next sections briefly introduce three of these tools. For more detailed information on these topics, please refer to the SAP online documentation or the SAP Help Web site.

ABAP Debugger

The ABAP Debugger can be activated from any transaction by entering the /H code in the transaction command field (also known as the OK-CODE). You can also activate the debugger by including the statement BREAK-POINT within the ABAP code. When the system processes the statement, the debugger is automatically activated. You can also use the macro keyword BREAK <username>. The debugger will only be activated when the program is run by the username in the program. Another more elegant way of setting up breakpoints is by using the options within the ABAP Editor.

Setting breakpoints in the ABAP Debugger

Setting breakpoints in the ABAP Debugger

In Figure, the developer has just located the cursor over the WRITE sentence and pressed the Stop button. At runtime, when the statement is processed, the system activates the debugger. Figure shows the ABAP Debugger.

Example of ABAP Debugger

Example of ABAP Debugger

If we enter the name of a data object of the program in the fields in the lower part of the debugger, the system will show the current contents of the field. With the Table button, we can see the content of an internal table. The Breakpoints button can be used to see all the existing control points within the program. The Watchpoints button allows seeing the watch points defined in the debugging process. A watchpoint is a conditional break point. There are many possible conditions for setting watchpoints, but the most common one is comparing a field value with the value of a constant or another program variable.

The Call button can be used to see the sequence of the current calls in the program. This sequence allows us to see the nesting of the calls between programs, function modules, ABAP processes, and so on. The Overview button is used to see the process blocks executed from the main program. With the Settings button we can configure how the debugger will behave. For example, we can set whether we also want to debug the system sentences.

Extended Program Check

The extended program check, invoked with transaction SLIN, is a tool that can be used to perform a comprehensive verification of our program. The functions that can be included with the transaction as well as some of the results of running it over a program.

Extended program check

Extended program check

SUN overview

SUN overview

In the initial field, we have to enter the name of the program to be analyzed. Next, we check those verifications to be performed.Tthe default values for these verifications. We could, for example, analyze those sentences that SAP already considers obsolete, or those that could create errors or dumps at runtime. In the resulting screen after running the analysis, we can identify the potential problems that might arise at runtime. You can exclude part of the program code if you include the following statements (during an extended syntax check, you can ignore these statements by using the additional function Include Suppressed Fields):

ABAP Units

The concept of unit testing is very common among Java developers, and the tool that normally is used for that type of testing is known, as Junit. ABAP Units work with a similar concept, but it is significantly different in its forms.
The most important concept of a test unit is to run a simple modularization unit of a program under certain valid testing conditions (specifically for input data) so that output can be analyzed. In this context, the routines (FORMS), function modules, and methods are units of an ABAP program. Steps to perform unit testing are the following:

  • Customize the input data for the ABAP modularization units.
  • Run the ABAP modularization unit.
  • Get and analyze the output data from the ABAP Unit.

The test units are implemented as local ABAP object classes within a main program. This does not mean that we can only test classes or instances methods. As indicated previously, we can test other usual object types, such as FORMS or function modules.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status