Documentation View

We are hiring and constantly growing! Have a look through our vacancies to find the right role for you!



ROGBILLS - Synchronize billing plans   BAL Application Log Documentation  
This documentation is copyright by SAP AG.
SAP E-Book


Short Reference

                                   $[DURATION ${SHORT$|MEDIUM$|LONG$}$].





The FOR TESTING addition is used to define a class as a whose purpose is for use with ABAP Unit. A class with the FOR TESTING addition can have different purposes:

  • Represent a test double for use as dependent-on-component in unit tests. For more information, see Managing Dependencies with ABAP Unit.
  • Provide helper functions (test infrastructure) for writing ABAP unit tests.

A test class and its components cannot be addressed in the production code of the program therefore, only in other test classes. In particular, a subclass of a test class must be a test class itself and be declared using the FOR TESTING addition. The only exception to this rule is that test classes can be specified as friends in the definition of production classes to make it possible to test private components.

A local test class can contain special private methods that implement the fixture for the tests of the class. These methods have the following predefined names:

  • An instance method setup, which is executed before each individual test that is before each execution of a test method of a class.
  • An instance method teardown, which is executed after each individual test that is after each execution of a test method of the class.
  • A static method class_setup, which is executed once before all tests of the class.
  • A static method class_teardown, which is executed once after all tests of the class.

The source code of a test class is not part of the production code of its program and is not generated in production systems (controlled using the profile parameter abap/test_generation). The code of such a class is not counted in code coverage measurements.


  • Local test classes of class pools and function pools should only be created in the test includes designed for them. In other programs, these tests should located at the end of the program.
  • In addition to the test methods and special methods for the fixture, a test class can also contain other components. These components can be used in a user's own test class only or in other test classes, depending on the visibility. In this way, help methods can be defined for tests.
  • All components required for tests in the context of ABAP Unit should be defined exclusively in test classes. This ensures that they cannot be generated in production systems and cannot be addressed by production code. In addition to test classes with test methods, this also includes test doubles and other helper classes that do not contain test methods.
  • Test classes can inherit from any other classes, especially global classes. This allows general global tests to be implemented that can be used in local test classes.
  • The special ABAP Doc comment "! @testing.can be written in front of the declaration of a test class in order to define a test relation for that class. This allows repository objects to be tested that do no support test classes themselves.
  • Global test classes (in a narrower sense) always have to define the code under test by means of a test relation.
  • In test classes, the addition PARTIALLY IMPLEMENTED of the statement INTERFACES can be specified, which allows interfaces to be implemented only partially. This is particularly useful in test doubles.
  • The addition FOR TESTING in a local class created in the area for local types of the class pool of a global test class. The addition is not needed in auxiliary classes for the global test class, since its property test class affects the entire class pool with regard to its generation. In rare cases in which a global test class is to be tested itself, local test classes can be created as recommended for other global classes in the area local test classes.
  • The methods of the fixture are not test methods and the addition FOR TESTING cannot be specified for their declaration.

Addition 1


Addition 2



These additions assign test properties to a test class.

  • RISK LEVEL defines the risk level for a test.
  • DURATION specifies the expected execution time.

During test execution, the test properties are checked against values that are maintained in transaction SAUNIT_CLIENT_SETUP.

  • The meaning of the risk levels is as follows:
  • CRITICAL - a test changes system settings or customizing data (default)

  • DANGEROUS - a test changes persistent data

  • HARMLESS - a test does not change system settings or persistent data

Tests whose risk level is higher than specified in transaction SAUNIT_CLIENT_SETUP are not executed.
  • The meaning of the expected execution time is as follows:
  • SHORT - an imperceptible execution time of some few seconds is expected.

  • MEDIUM - a noticeable execution time of around a minute is expected.

  • LONG - a very noticeable execution time of more than one minute is expected.

For each of these expected execution times, upper limits are specified in transaction SAUNIT_CLIENT_SETUP. These limits are usually greater than the expected execution times in order to include processes, as e.g. compilations, that are not part of the test itself. If a test exceeds the upper limit associated with the expected time, the system behavior depends on the so-called execution mode of the test and whether the ABAP Unit runtime monitoring is switched on or off. For more information about execution mode and runtime monitoring, see the documentation of transaction SAUNIT_CLIENT_SETUP or ABAP Unit in SAP Help Portal.


  • Note the difference between expected execution time specified by DURATION and the allowed execution time specified by the respective upper limit in transaction SAUNIT_CLIENT_SETUP. The expected execution time must be defined according to the actual expectation and not to the upper limit, in order to avoid system-dependent test abortions.


See the program DEMO_ABAP_UNIT.

  • A class demo represents the production part of the source code. A method get_sum adds the values of the fields of a row of a DDIC database table and assigns the result to the private attribute sum.
  • The class test_demo is a test class for the class demo.
  • In the method setup, an object of demo is created and the DDIC database table is prepared with test data. Therefore, the addition DANGEROUS is specified for RISK LEVEL.

  • The method test_sum calls get_sum and compares the private attribute sum with the expected value. For this reason, test_demo must be a friend of the class demo.

  • In the method teardown, the test data is removed from the DDIC database table again.

The test method is called when the unit test of DEMO_ABAP_UNIT is executed and should not report an error.

CL_GUI_FRONTEND_SERVICES - Frontend Services   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.

Length: 12821 Date: 20230328 Time: 165522     sap01-206 ( 210 ms )