ABAP ASSERT Statement Explained: Assertions for Test & Debugging

The ASSERT statement is used to make assertions about the state of your program at runtime and to verify them. An assertion is a condition that you as a developer firmly assume to be always true (abap_true) at a specific point in the code.

ASSERT is primarily a tool for:

• Development and Testing: To detect logical errors in the program or incorrect assumptions about data states early.
• Debugging: To quickly determine at which point an assumption was violated.
• Code Documentation: To explicitly document assumptions about the program state in the code.

Important Distinction: ASSERT is not intended for normal error handling (e.g., invalid user input, expected error conditions in business logic) in production environments. For that, you should use IF statements, MESSAGE, RAISE EXCEPTION, etc. ASSERT checks for programming errors or states that should “never” actually occur.

Syntax

ASSERT [ ID <assertion_group> ]
       [ SUBKEY <subkey> ]
       [ FIELDS <field1> <field2> ... ]
       CONDITION <logical_expression>. " The keyword CONDITION is mandatory!

• ID <assertion_group> (Optional): Assigns the assertion to a so-called “checkpoint group” or “assertion group”. These groups can be activated, deactivated, or configured centrally (transaction SAAB). This is very useful for controlling the behavior of assertions system-wide or user-specifically.
• SUBKEY <subkey> (Optional): An additional text (subkey) for further identification or contextualization of the assertion within an ID group.
• FIELDS <field1> <field2> ... (Optional): Here you can specify a list of data objects (variables). If the assertion fails, the values of these fields are displayed in the log or in the short dump, which significantly simplifies troubleshooting.
• CONDITION <logical_expression>: Mandatory! This is the logical expression that is evaluated. The assertion is considered fulfilled (successful) if this expression evaluates to abap_true.

Behavior on Failure

At runtime, the <logical_expression> is checked:

1. If the condition is abap_true (true): The assertion is fulfilled. Nothing further happens, and the program continues normally. Your assumption about the program state was correct.
2. If the condition is abap_false (false): The assertion fails. What happens now depends on the activation setting of the assertion (controlled via the ID, SUBKEY in transaction SAAB or global system parameters):
   • Inactive: The ASSERT statement is completely ignored. It has no effect on execution or performance. This is the default setting for production systems.
   • Active - Mode ‘Log’: The assertion failure is logged (e.g., in the system log, transaction SM21, or in a special log for checkpoint groups). The values specified under FIELDS can be logged along with it. The program continues afterwards. This mode is useful in test or quality assurance systems.
   • Active - Mode ‘Abort’/‘Break’: The program aborts with a runtime error (short dump) of type ASSERTION_FAILED, or it stops in the debugger at this point (depending on the setting). This is often the desired setting during the development phase to immediately become aware of the logical error.

Use Cases

• Checking preconditions for methods or function modules (e.g., ASSERT CONDITION parameter IS NOT INITIAL.).
• Checking postconditions after executing code blocks (e.g., ASSERT CONDITION result > 0.).
• Checking invariants (states that should always hold, e.g., within a loop or for an object, ASSERT CONDITION object_ref IS BOUND.).
• Safeguarding against “impossible” states in CASE or IF structures (e.g., in the WHEN OTHERS branch of a CASE statement where you don’t expect any other case: ASSERT CONDITION 1 = 0.).

Examples

1. Simple Precondition Check

METHOD calculate_price.
  IMPORTING quantity TYPE i.

  " Assumption: Quantity must not be negative for this calculation
  ASSERT CONDITION quantity >= 0.

  " ... Price calculation ...
ENDMETHOD.

2. Postcondition Check with FIELDS

DATA total TYPE p DECIMALS 2.
DATA item_count TYPE i.

" ... Code that calculates total and item_count ...

ASSERT ID zmy_calc_group SUBKEY 'FinalCheck'
       FIELDS total item_count
       CONDITION total >= 0 AND ( item_count = 0 OR total > 0 ).
" Assumption: Total sum never negative; if items exist, sum must be > 0.

3. Checking an Object Reference

DATA factory TYPE REF TO zcl_my_factory.
DATA instance TYPE REF TO zif_my_interface.

factory = zcl_my_factory=>get_instance( ).
ASSERT CONDITION factory IS BOUND. " Assumption: Factory always exists

instance = factory->create_object( type = 'A' ).
ASSERT CONDITION instance IS BOUND. " Assumption: Object was created successfully

instance->do_work( ).

Important Notes / Best Practice

• Use ASSERT as a quality assurance tool during development and testing, not for handling expected runtime errors in production systems.
• Always use the ID addition to make your assertions controllable via SAAB. Choose meaningful group names.
• Use the FIELDS addition to see relevant variable values in case of failure.
• Ensure that assertions are inactive by default in production systems to avoid performance losses or unwanted aborts. Activation is then done specifically when needed for analysis.
• Write assertions for all non-trivial assumptions you make about your code or data.