ABAP Unit - TDF (Test Double)

Table of contents

• General
• Terms
• Example
• Procedure
• Conclusion

The Test Double Framework (for short TDF) provides tools to generate so-called doubles for the objects class, table and core data service (CDS) during the test period and to test them against them. This technique is intended to reduce dependencies on objects that are difficult to test and focus on testing the actual component (class).

 

General

A test double should deactivate dependent components in a test case in order to enable a controlled test of the logic and thus not to be dependent on other objects and their status. Since a unit test only tests the current component (class), dependent components (DOC - Depend-On Component) must be deactivated or checked if possible.

 

In example (1) you can see the component that is used by our class under test. When preparing the test (2), you then simply exchange the component with a test double and thus reduce dependencies on your test cases.

Hint: A global interface is always required to generate a test double and is a mandatory requirement.

 

Terms

Again, and again, when using test doubles, you will come across different terms that only describe the test double in its function. Here is a list of the names and functions:

• Test Double - General term for all types of doubles
• Stub - Provides indirect input
• Spy - Logs indirect output
• Fake - Simplest implementation of a test double
• Mock - Extension for stub, spy and fake of indirect input / output validated
• Dummy - No logic, just to adhere to the syntax

 

 

Example

In the following example, the class to be tested has a dependent component that triggers output as an ALV. This output would prevent our test and trigger a crash, since no GUI components work in unit tests. For this reason, we need a test double in order to be able to test our class properly and to have to adapt as little coding as possible.

The class that we want to test looks like this, but for the sake of simplicity we have included the dependent component in the PUBLIC area.

CLASS zcl_bs_demo_double_class DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    DATA:
      mo_uicomponent TYPE REF TO zif_test_display.

    METHODS:
      constructor,

      select_and_show_data
        IMPORTING
                  id_short_name       TYPE zbs_dy_tools-short_name
        RETURNING VALUE(rd_displayed) TYPE abap_bool.

  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zcl_bs_demo_double_class IMPLEMENTATION.
  METHOD constructor.
    mo_uicomponent = NEW zcl_test_display( ).
  ENDMETHOD.


  METHOD select_and_show_data.
    SELECT *
      FROM zbs_dy_tools
      WHERE short_name = @id_short_name
     INTO TABLE @DATA(lt_found_tools).

    rd_displayed = mo_uicomponent->display_generic_data( lt_found_tools ).
  ENDMETHOD.
ENDCLASS.

 

To do this, we create the following test class, which should now test our class automatically:

CLASS ltc_double_access DEFINITION FINAL FOR TESTING
  DURATION SHORT
  RISK LEVEL HARMLESS.

  PRIVATE SECTION.
    METHODS:
      selection_without_ui FOR TESTING.
ENDCLASS.

CLASS ltc_double_access IMPLEMENTATION.
  METHOD selection_without_ui.
    DATA:
      lt_dummy_data TYPE STANDARD TABLE OF zbs_dy_tools.

    DATA(lo_cut) = NEW zcl_bs_demo_double_class( ).

    " Step 1
    lo_cut->mo_uicomponent = CAST #( cl_abap_testdouble=>create( 'zif_test_display' ) ).

    " Step 2
    cl_abap_testdouble=>configure_call( lo_cut->mo_uicomponent )->ignore_parameter( 'IT_DATA' )->returning( abap_true ).

    " Step 3
    lo_cut->mo_uicomponent->display_generic_data( lt_dummy_data ).

    DATA(ld_result) = lo_cut->select_and_show_data( 'SCREWDRIVER' ).

    cl_abap_unit_assert=>assert_true( ld_result ).
  ENDMETHOD.
ENDCLASS.

 

In the test method, we create the CUT object and prepare the test double. To do this, a few steps are taken. Then we call up the method to be tested again.

 

Procedure

The procedure for using a test double must be followed, otherwise the double will not work correctly:

• Generation of the double via the global interface (step 1)
• Configuration of the double and the expected parameters (step 2)
• Call of the dependent method before the actual call of the test method to transfer the import parameters (step 3)

 

Hint: These steps must be followed so that the double works properly and the test case works.

 

Conclusion

The test double is the oldest method for testing DOCs and already exists on older releases, well before S/4 HANA and New ABAP. Once you understand the setup and call methodology, it shouldn't be a problem to use it.