This is a test message to test the length of the message box.
Login
ABAP Unit TDF SQL Double
Created by Software-Heroes

ABAP Unit - TDF (SQL Double)

In this article we take a closer look at the SQL Double and how you can gain independence from the database.

Advertising

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

The SQL double has the task of replacing the database layer and thus replacing all requests (CRUD) on one or more tables with a corresponding double. The tables can be specified during generation. The following overview of the actual test:

 

Point 1) shows the normal test scenario without the test double, the accesses of the code under test always go to the correct data in the database. Point 2) shows the goal, we have exchanged the data in the table with a double, all CRUD operations run against the double and are thus secured by us.

 

Data exchange

However, we do not exchange the data directly on the database; it is available at all times and remains consistent. The generated test double is available to us for our test class and is removed again after it has been carried out.

The advantage of this technique is the stability of our test cases, as we cannot be sure that our test data in the database will not change. With this technique, the data for our tests always remains the same and you do not have to outsource access to the database to other classes or even adjust them.

 

Example

In order to bring you closer to the use of the methodology, we want to illustrate the topic with an example. We want to replace the following table with a double:

 

The table contains some data sets that should be sufficient for our tests:

 

For this purpose, we are now building a corresponding class against which we can then run our test class. For this we only need a simple reading routine, to which we transfer a key and then receive the result of the database selection.

CLASS zcl_bs_demo_double_sql DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    METHODS:
      select_tool
        IMPORTING
                  id_sname       TYPE char25
        RETURNING VALUE(rs_tool) TYPE zbs_dy_tools.

  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zcl_bs_demo_double_sql IMPLEMENTATION.
  METHOD select_tool.
    SELECT SINGLE *
      FROM zbs_dy_tools
      WHERE short_name = @id_sname
      INTO @rs_tool.
  ENDMETHOD.
ENDCLASS.

 

The corresponding test class now looks like this.

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

  PRIVATE SECTION.
    CLASS-DATA:
      go_environment TYPE REF TO if_osql_test_environment.

    CLASS-METHODS:
      class_setup,
      class_teardown.

    METHODS:
      positive_case FOR TESTING,
      negative_case FOR TESTING.
ENDCLASS.


CLASS ltc_db_access IMPLEMENTATION.
  METHOD class_setup.
    DATA:
      lt_data TYPE STANDARD TABLE OF zbs_dy_tools WITH EMPTY KEY.

    go_environment = cl_osql_test_environment=>create( VALUE #( ( 'ZBS_DY_TOOLS' ) ) ).

    lt_data = VALUE #(
      ( short_name = 'SAW' stock_quantity = 15 )
      ( short_name = 'WRENCH' stock_quantity = 0 )
      ( short_name = 'NAIL' stock_quantity = 250 )
    ).

    go_environment->insert_test_data( lt_data ).
  ENDMETHOD.


  METHOD class_teardown.
    go_environment->destroy( ).
  ENDMETHOD.


  METHOD positive_case.
    DATA(lo_cut) = NEW zcl_bs_demo_double_sql( ).

    DATA(ls_result) = lo_cut->select_tool( 'NAIL' ).

    cl_abap_unit_assert=>assert_not_initial( ls_result ).
  ENDMETHOD.


  METHOD negative_case.
    DATA(lo_cut) = NEW zcl_bs_demo_double_sql( ).

    DATA(ls_result) = lo_cut->select_tool( 'HAMMER' ).

    cl_abap_unit_assert=>assert_initial( ls_result ).
  ENDMETHOD.
ENDCLASS.

 

Procedure

As you can see in the example above, a few steps are necessary for the preparation and we use the help methods CLASS_SETUP and CLASS_TEARDOWN for this.

  • In the setup method, the SQL environment is first set up and the tables to be exchanged are specified
  • Transfer of the test data to the environment
  • Execution of the test cases against the test data
  • Breakdown of the environment when breaking down the test class

 

The data can also be made available in SETUP, for this purpose the data is transferred to the method and the SQL double is cleared beforehand with CLEAR_DOUBLES. The method deletes the existing data and empties all tables. Deleting the data from the table is mainly used when you want to test CRUD operations against the tables.

 

Conclusion

With the test double framework, you can bridge and exchange various components during the test period in order to reduce the test to your code. With the SQL Double you make sure that your accesses find the data you want.


Included topics:
ABAP UnitABAPUnit TestsTest-Double-FrameworkSQL Double
Comments (0)
Advertising

ABAP Unit - Tips

Category - ABAP

At the end of the series, a few tips that we would like to give you along the way. This is about shortcuts and general information about the tests.

11/12/2021

ABAP Unit - Software architecture

Category - ABAP

What could the target architecture look like in a SAP system if we look at our own software components? We want to clarify this in this article.

11/05/2021

ABAP Unit - Testable Code (Part 3)

Category - ABAP

Here we take a closer look at the options for deactivating dependent components in your own coding during the test period.

10/29/2021

ABAP Unit - Testable Code (Part 2)

Category - ABAP

This article is about test isolation and how it makes our code more testable.

10/22/2021

ABAP Unit - Testable Code (Part 1)

Category - ABAP

In this article, we'll look at how you can cleanly implement new functions in older code and then test it.

10/08/2021