
In a previous post, I provided a [real world example of ABAP unit testing](/blog/real-world-example-of-abap-unit-testing). This approach involved unit tests directly interacting with the database, using a simple report based on the SFLIGHT sample data. While this method doesn't strictly conform to unit testing principles, it allows for effective testing thanks to the isolation and consistent starting point offered by the SAP system on [Nuve Platform](/platform). 

Recently, an insightful reader suggested considering the use of 'test doubles' as an alternative testing approach. Inspired by this idea, today's post will explore the application of 'test doubles' for mock data. We'll compare this strategy with direct database interaction, examining the pros and cons of each.


# Testing with real data
This approach entails unit tests designed to directly interact with the database, using real data to validate the logic of the code. This method is often likened to an integration testing strategy, as the code under test isn't isolated from its dependencies.

## Pros
- Realistic scenarios: By using actual data, the testing environment closely mirrors production scenarios.
- Integration verification: This approach facilitates the detection of issues within the system as a whole.

## Cons
- Data dependence: The success of the tests is tied to the current state of the database, potentially resulting in inconsistent outcomes.
- Potential performance issues: Direct interactions with the database may slow down the testing process.

# Testing with test doubles
This strategy employs 'test doubles'—predefined test data as a substitute for real data from the database. This method aligns closely with classic [unit testing practices](/blog/principles-and-practices-of-abap-unit-testing), where the class or method under test is isolated from its dependencies.

## Pros
- Consistency: These tests are generally more reliable, yielding consistent results irrespective of the database's state.
- Speed: Since there's no need for database interaction, test doubles can expedite the testing process.

## Cons
- Artificial scenarios: Test doubles may not accurately reflect real-world scenarios.
- Extra implementation: Creating and maintaining test doubles requires extra effort.

> ### Ready to level up your unit testing? 
> With Nuve Platform, refactor code at your own pace without disruptions. Check out our plans and [start your journey today](/pricing).

# 

# Updated code

In the latest iteration of our code, we've introduced noteworthy changes. By leveraging an interface, we've successfully implemented a test double class. This enhancement substantially bolsters our capability to perform unit-level testing for each class. Particularly when access to containerized SAP systems on Nuve isn't available to spin up from a known state, this upgrade in our testing approach paves the way for more precise and efficient testing outcomes.
#

```abap
REPORT zairline_info.

*********************************************************************************************
* Functional code
*********************************************************************************************
TYPES: BEGIN OF s_sflight,
         mandt      TYPE s_mandt,
         carrid     TYPE s_carr_id,
         connid     TYPE s_conn_id,
         fldate     TYPE s_date,
         price      TYPE s_price,
         currency   TYPE s_currcode,
         planetype  TYPE s_planetye,
         seatsmax   TYPE s_seatsmax,
         seatsocc   TYPE s_seatsocc,
         paymentsum TYPE s_sum,
         seatsmax_b TYPE s_smax_b,
         seatsocc_b TYPE s_socc_b,
         seatsmax_f TYPE s_smax_f,
         seatsocc_f TYPE s_socc_f,
       END OF s_sflight.

TYPES: t_sflight TYPE TABLE OF s_sflight.

INTERFACE zif_airline_capacity.
  METHODS:
    get_data
      IMPORTING
        iv_carrid TYPE s_sflight-carrid,
    get_total_capacity
      RETURNING
        VALUE(rv_total_capacity) TYPE i,
    get_used_capacity
      RETURNING
        VALUE(rv_used_capacity) TYPE i,
    get_available_capacity
      RETURNING
        VALUE(rv_available_capacity) TYPE i.

ENDINTERFACE.

CLASS zcl_airline_capacity DEFINITION.
  PUBLIC SECTION.
    INTERFACES: zif_airline_capacity.
  PROTECTED SECTION.
    DATA: lt_sflight_data TYPE t_sflight,
          ls_sflight_data TYPE s_sflight.
ENDCLASS.

CLASS zcl_airline_capacity IMPLEMENTATION.
  METHOD zif_airline_capacity~get_data.
    SELECT *
      INTO TABLE @lt_sflight_data
      FROM sflight
      WHERE carrid = @iv_carrid.

  ENDMETHOD.

  METHOD zif_airline_capacity~get_available_capacity.
    LOOP AT lt_sflight_data INTO ls_sflight_data.
      rv_available_capacity = rv_available_capacity + ( ls_sflight_data-seatsmax + ls_sflight_data-seatsmax_b + ls_sflight_data-seatsmax_f - ls_sflight_data-seatsocc - ls_sflight_data-seatsocc_b - ls_sflight_data-seatsocc_f ).

    ENDLOOP.

  ENDMETHOD.

  METHOD zif_airline_capacity~get_used_capacity.
    LOOP AT lt_sflight_data INTO ls_sflight_data.
      rv_used_capacity = rv_used_capacity + ( ls_sflight_data-seatsocc + ls_sflight_data-seatsocc_b + ls_sflight_data-seatsocc_f ).

    ENDLOOP.

  ENDMETHOD.

  METHOD zif_airline_capacity~get_total_capacity.
    LOOP AT lt_sflight_data INTO ls_sflight_data.
      rv_total_capacity = rv_total_capacity + ( ls_sflight_data-seatsmax + ls_sflight_data-seatsmax_b + ls_sflight_data-seatsmax_f ).

    ENDLOOP.

  ENDMETHOD.

ENDCLASS.

*********************************************************************************************
* Test double
*********************************************************************************************
CLASS zcl_airline_capacity_td DEFINITION INHERITING FROM zcl_airline_capacity FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.
  PUBLIC SECTION.
    METHODS zif_airline_capacity~get_data REDEFINITION.

ENDCLASS.

CLASS zcl_airline_capacity_td IMPLEMENTATION.
  METHOD zif_airline_capacity~get_data.
    ls_sflight_data = VALUE #( mandt = 800 carrid = 'AA' connid = 2402 fldate = '20230601' price = 300 currency = 'USD'
                               planetype = '747-400' seatsmax = 400 seatsocc = 200 paymentsum = 30000 seatsmax_b = 80 seatsocc_b = 40
                               seatsmax_f = 70 seatsocc_f = 35 ).
    INSERT ls_sflight_data INTO TABLE lt_sflight_data.

    ls_sflight_data = VALUE #( mandt = 800 carrid = 'AA' connid = 2401 fldate = '20230602' price = 250 currency = 'USD'
                               planetype = '747-400' seatsmax = 400 seatsocc = 150 paymentsum = 25000 seatsmax_b = 80 seatsocc_b = 30
                               seatsmax_f = 70 seatsocc_f = 30 ).
    INSERT ls_sflight_data INTO TABLE lt_sflight_data.

  ENDMETHOD.

ENDCLASS.

*********************************************************************************************
* Unit tests
*********************************************************************************************
CLASS ltc_airline_capacity_tests DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.
  PRIVATE SECTION.
    DATA: mo_airline_capacity TYPE REF TO zcl_airline_capacity_td.

    METHODS:
      setup,
      test_get_total_capacity FOR TESTING,
      test_get_used_capacity FOR TESTING,
      test_get_available_capacity FOR TESTING,
      test_capacity_relationship FOR TESTING.

ENDCLASS.

CLASS ltc_airline_capacity_tests IMPLEMENTATION.
  METHOD setup.
    CREATE OBJECT mo_airline_capacity TYPE zcl_airline_capacity_td.
    mo_airline_capacity->zif_airline_capacity~get_data( 'AA' ).

  ENDMETHOD.

  METHOD test_get_total_capacity.
    DATA: lv_total_capacity TYPE i.

    lv_total_capacity = mo_airline_capacity->zif_airline_capacity~get_total_capacity( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_total_capacity
      exp = 1100
      msg = 'Total capacity is not correct'
    ).

  ENDMETHOD.

  METHOD test_get_used_capacity.
    DATA: lv_used_capacity TYPE i.

    lv_used_capacity = mo_airline_capacity->zif_airline_capacity~get_used_capacity( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_used_capacity
      exp = 485
      msg = 'Used capacity is not correct'
    ).

  ENDMETHOD.

  METHOD test_get_available_capacity.
    DATA: lv_available_capacity TYPE i.

    lv_available_capacity = mo_airline_capacity->zif_airline_capacity~get_available_capacity( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_available_capacity
      exp = 615
      msg = 'Available capacity is not correct'
    ).

  ENDMETHOD.

  METHOD test_capacity_relationship.
    DATA: lv_total_capacity     TYPE i,
          lv_available_capacity TYPE i,
          lv_used_capacity      TYPE i.

    lv_total_capacity = mo_airline_capacity->zif_airline_capacity~get_total_capacity( ).
    lv_used_capacity = mo_airline_capacity->zif_airline_capacity~get_used_capacity( ).
    lv_available_capacity = mo_airline_capacity->zif_airline_capacity~get_available_capacity( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_total_capacity
      exp = lv_available_capacity + lv_used_capacity
      msg = 'Total capacity should be equal to the sum of available and used capacity'
    ).

  ENDMETHOD.

ENDCLASS.

*********************************************************************************************
* Execute code
*********************************************************************************************
START-OF-SELECTION.

  DATA: lo_airline_capacity TYPE REF TO zcl_airline_capacity,
        available_capacity  TYPE i,
        used_capacity       TYPE i,
        total_capacity      TYPE i.

  CREATE OBJECT lo_airline_capacity.
  lo_airline_capacity->zif_airline_capacity~get_data( 'AA' ).

  available_capacity = lo_airline_capacity->zif_airline_capacity~get_available_capacity( ).
  used_capacity = lo_airline_capacity->zif_airline_capacity~get_used_capacity( ).
  total_capacity = lo_airline_capacity->zif_airline_capacity~get_total_capacity( ).

  WRITE: / 'The available capacity for airline AA is:', available_capacity.
  WRITE: / 'The used capacity for airline AA is:     ', used_capacity.
  WRITE: / 'The total capacity for airline AA is:    ', total_capacity.
```

# Unit Testing: An Evolving Practice

The application of test doubles creates a controlled environment that isolates the code from external dependencies, enhancing the predictability of test outcomes. It's crucial to understand that using test doubles doesn't lessen the value of real data testing. Instead, it offers an alternative method that can be effective in various contexts.

Real data testing remains pivotal for validation. However, when isolation and a consistent starting point aren't provided by systems like Nuve, test doubles can deliver consistency and efficiency.

Real data testing and test doubles should be viewed as complementary strategies. Each has its place within a comprehensive testing suite. Real data tests prove particularly useful for integration testing, while test doubles shine in unit testing scenarios.

# Key Takeaways

The decision between real data testing and test doubles depends on the specific scenario and the requirements of the test. Both strategies have their strengths and can be deployed effectively in the right context. Understanding these approaches equips ABAP developers with the tools to develop a more robust, reliable, and efficient testing process—ultimately enhancing the overall quality of their code.

Happy testing!


Balancing real data and test doubles in ABAP testing

We explore two methods of ABAP testing - using real data and test doubles. Learn their advantages, drawbacks, and ideal scenarios, providing a comprehensive understanding of how to effectively implement these strategies for robust and efficient testing.

A look into ABAP unit testing approaches

Related posts

Fundamentals of ABAP unit testing

Principles and practices of ABAP unit testing

The role of unit testing in ABAP code refactoring