
Testing is a vital aspect of software development, ensuring the stability, reliability, and performance of your applications. In the SAP ecosystem, ABAP Unit testing is an underutilized but important approach for validating custom code. 

In this blog post, we will explore the basics of testing in SAP, how to set up and configure ABAP Unit tests, and provide some examples to illustrate the different risk levels within the context of a "Hello World" program. For a more advanced example, be sure to read [ABAP Unit testing](/blog/real-world-example-of-abap-unit-testing).

# ABAP unit testing in SAP

To run ABAP Unit tests in SAP, you must work within a client that has the appropriate role assigned via the transaction code `SCC4`. Only clients with roles such as Customizing, Demo, Training/education, and Test are suitable for running tests. Production and SAP Reference clients do not allow test execution to preserve system stability and data integrity.

# Configuring ABAP unit tests

To configure your ABAP Unit tests, use the transaction code `SAUNIT_CLIENT_SETUP`. This transaction code offers several options for tailoring your tests:

1. Prohibit the execution of tests: Prevent tests from running in certain clients.
2. Limit the risk level: Define the acceptable risk levels for test execution - Harmless, Dangerous, or Critical.
3. Define the duration of tests: You can set a time limit for test execution in seconds, ensuring that tests do not run indefinitely and consume valuable system resources.

### Risk levels explained
- CRITICAL: Tests that involve changes to system settings or Customizing
- DANGEROUS: Tests that involve changes to persistent data
- HARMLESS: Tests that have no effects on persistent data or system settings

A Harmless test could validate the output of a straightforward message display function. For instance, if a program is designed to display Hello World!, your test could confirm that the generated output string matches the anticipated value.

A Dangerous test could involve checking the creation of a temporary record in a database table, while a Critical test might assess the impact of a configuration change on the program's behavior.

### Duration of tests explained
The duration of tests in ABAP Unit is an attribute that helps to categorize test cases based on the expected time they take to execute. When defining a test class for ABAP Unit tests, you can specify the expected duration using one of the following options:

- SHORT: The test is expected to complete quickly, usually within seconds. These tests are often simple, with minimal overhead, and are designed to be executed frequently, such as during development or as part of a continuous integration process.
- MEDIUM: The test is expected to take a moderate amount of time, possibly a few minutes. These tests may involve more complex logic, access to external resources, or a larger amount of data. They may be executed less frequently than short tests, such as during integration testing or before deploying changes to production.
- LONG: The test is expected to take a significant amount of time to complete, possibly hours. These tests are typically used for complex scenarios, stress testing, or end-to-end system testing. Due to their duration, long tests are generally executed less frequently, such as during specific testing phases or at certain milestones in the project lifecycle.

By specifying the test duration, you help set expectations for test execution time, which can be useful when organizing and prioritizing tests. Additionally, it allows developers and testers to ensure that the testing process is efficient and that time-sensitive tests are executed promptly.

# Example implementation

```abap
REPORT ZHELLO_WORLD.

* Local Class definition
CLASS LCL_HELLO_WORLD DEFINITION FINAL CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS: DISPLAY_MESSAGE
               RETURNING VALUE(rv_result) TYPE STRING.
ENDCLASS.

* Local Class implementation
CLASS LCL_HELLO_WORLD IMPLEMENTATION.

  METHOD DISPLAY_MESSAGE.
    rv_result = 'Hello World!'.
  ENDMETHOD.

ENDCLASS.

* Local Test class definition
CLASS LTCL_HELLO_WORLD_TEST DEFINITION FOR TESTING
  RISK LEVEL HARMLESS
  DURATION SHORT
  FINAL.

  PRIVATE SECTION.
    DATA: mo_hello_world TYPE REF TO LCL_HELLO_WORLD.

    METHODS: setup,
             test_display_message FOR TESTING.
ENDCLASS.

* Local Test class implementation
CLASS LTCL_HELLO_WORLD_TEST IMPLEMENTATION.

  METHOD setup.
    CREATE OBJECT mo_hello_world.
  ENDMETHOD.

  METHOD test_display_message.
    DATA: lv_output TYPE STRING.

    lv_output = mo_hello_world->DISPLAY_MESSAGE( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_output
      exp = 'Hello World!'
      msg = 'Unexpected output' ).
  ENDMETHOD.

ENDCLASS.

* Report execution
START-OF-SELECTION.
  DATA: go_hello_world TYPE REF TO LCL_HELLO_WORLD.

  CREATE OBJECT go_hello_world.
  WRITE: / go_hello_world->DISPLAY_MESSAGE( ).
```

In this ABAP code example, we have a simple program designed to display the message "Hello World!". The program consists of a local class `LCL_HELLO_WORLD`, which has a single method called `DISPLAY_MESSAGE`. This method returns the string "Hello World!" when called.

To ensure the program works correctly, we're using ABAP Unit testing. We create a local test class `LTCL_HELLO_WORLD_TEST` with a `FOR TESTING` statement, specifying the risk level as Harmless and the test duration as Short. This test class contains two methods: `setup` and `test_display_message`.

The `setup` method is used to initialize the test environment by creating an instance of the `LCL_HELLO_WORLD` class. The `test_display_message` method contains the actual test logic. It calls the `DISPLAY_MESSAGE` method of the `LCL_HELLO_WORLD` class and stores the output in a variable `lv_output`. Then, it uses `cl_abap_unit_assert=>assert_equals` to compare the actual output (`lv_output`) with the expected value ('Hello World!').

If the output matches the expected value, the test passes, indicating that the `DISPLAY_MESSAGE` method works as intended. If not, the test fails, signaling that there might be an issue with the program's implementation.

### Step-by-step example

Let's walk through a possible real-world example. I encourage you to try this in a system if you have access to one. 

Imagine a new ABAP dev, Ali, decides to edit this code and changes the class implementation method.
```abap
  METHOD DISPLAY_MESSAGE.
    rv_result = 'Hello World'.
  ENDMETHOD.
```

Luckily, Ali knows the value of tests so he executes the ABAP Unit test in SAP GUI. Windows: `Ctrl + Shift + F10` Mac OS: `fn + Control + Shift + F10` The results show Ali a very helpful message. **Expected "Hello World!" Actual "Hello World"** This is because Ali removed the exclamation mark in the updated method.
![Failed Test](/images/blog/abap-unit/failed-test.png)

Ali realizes this is important and reverts his change. Naturally, he executes the ABAP Unit tests again. This time, the test passes. 
![Passing Test](/images/blog/abap-unit/passing-test.png)


Even though this is a simple example, ABAP Unit testing is crucial for validating the functionality of your custom code in the SAP ecosystem. By writing and executing unit tests, you can ensure your code behaves as expected, allowing you to catch and fix any issues before they make their way into the production environment. This is particularly helpful if you are writing programs that need to work across multiple SAP versions. The ABAP Unit tests allow you to catch errors early and identify the exact part of the code that needs to be updated. 



A beginners guide to implementing and configuring ABAP unit tests

Dive into the world of ABAP Unit testing in SAP, exploring the fundamentals of testing, setting up and configuring tests, and understanding risk levels and test durations.

Fundamentals of ABAP unit testing

Related posts

Fundamentals of ABAP unit testing

Getting started with abaplint

Principles and practices of ABAP unit testing