In software development, changes are inevitable. Keeping your code reliable can be challenging. Unit testing is a powerful tool that helps developers ensure their code is robust, adaptable, and less prone to errors.

In this second installment of our ABAP Unit Testing series, we explore the importance of unit tests in ABAP, discuss their benefits, and offer practical examples using SFLIGHT-related data. Be sure to revisit our earlier post on the fundamentals of ABAP Unit Testing.

Let's dive in!

Software Evolves

Unit tests focus on validating small portions of your code, such as methods or functions, to guarantee they perform as intended. Integrating unit tests into your development workflow enables you to identify potential problems early, minimizing the time and effort needed for later fixes.

As software evolves, modifications to the code may inadvertently break existing functionality. However, with well-designed unit tests in place, you can detect issues early on. This is crucial when updating code after extended periods or working with code written by others. Good unit tests also serve as living documentation, making it easier for you and your colleagues to understand and maintain the code.

The number of test cases continues to grow as you add functionality. While human testing is essential, keeping track of all test scenarios is challenging and time-consuming. Unit tests, on the other hand, offer a consistent and reliable approach to verifying that existing functionality remains functional.

Robotic Helper

Have you ever encountered a situation where you need to add a feature and there's a clean way to refactor the code, but you're hesitant to make changes due to the fear of introducing new bugs into production? As requirements change and your code evolves, unit tests can serve as a safety net, ensuring that modifications don't create new issues or regressions. By running your tests after each change, you can confidently maintain the stability and functionality of your existing code. Think of unit tests as a robotic helper assisting you with your work.

Along those lines, humans sometimes forget. You can automate the execution of unit tests with continuous integration (CI) tools. This approach can further optimize your workflow and enhance your code's reliability.

Risky? No worries with isolated systems!

Some tests might be risky, potentially causing harm to the system if executed in a shared environment. Thankfully, ABAP Unit allows you to define the risk level for each system, enabling you to run risky tests in isolated systems and harmless tests in shared systems. This way, you can test with confidence without affecting system stability in a shared environment.

The top 1% of ABAP developers unit test

Top-tier developers recognize the importance of unit testing and make it an integral part of their development process. However, there's an even greater reason to embrace unit testing for those who may not be among the elite developers. If you often find yourself addressing issues later in the development process, implementing unit tests can be a game-changer. By adopting unit testing, you will notice reduced rework and result in happier functional users and a more satisfied boss. By delivering more reliable software, you'll foster a more productive and positive work environment for everyone involved.

Real-World Example

Before diving into the example, let's briefly introduce the SFLIGHT data model used in this scenario. SFLIGHT is a standard SAP data model that simulates a simple flight reservation system. It includes several tables containing information about flights, carriers, connections, and bookings. In this example, we will be working primarily with the SFLIGHT table, which contains data on individual flights and their seat capacities.

Initial Requirement

You work at an international airport on their development team. Your colleague, Mary, is an operations manager responsible for monitoring seat capacity and allocation across flights operated by different airlines.

Mary recognizes the importance of having a comprehensive view of the total, available, and used seat capacity for each airline, identified by their carrier ID. This information would enable her to conduct more informed analyses. She requires a solution that calculates and presents these capacity details, streamlining her data analysis and decision-making process.

Mary presents her request to the IT team:

"I would like a program that can calculate and display the following information by airline:

• Available capacity - The number of seats still available for booking across all flights.
• Used capacity - The number of seats that have already been booked across all flights.
• Total capacity - The total number of seats available across all flights.

With a clear understanding of the requirements, you initiate the development of the ZAIRLINE_INFO report to address this business need.

REPORT zairline_info.

CLASS zcl_airline_capacity DEFINITION.
  PUBLIC SECTION.
    METHODS:
      get_available_capacity
        IMPORTING
          iv_carrid                    TYPE s_carr_id
        RETURNING
          VALUE(rv_available_capacity) TYPE i,
      get_used_capacity
        IMPORTING
          iv_carrid               TYPE s_carr_id
        RETURNING
          VALUE(rv_used_capacity) TYPE i,
      get_total_capacity
        IMPORTING
          iv_carrid                TYPE s_carr_id
        RETURNING
          VALUE(rv_total_capacity) TYPE i.
ENDCLASS.

CLASS zcl_airline_capacity IMPLEMENTATION.
  METHOD get_available_capacity.
    SELECT SUM( seatsmax + seatsmax_b + seatsmax_f - seatsocc - seatsocc_b - seatsocc_f )
       INTO @rv_available_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.

  METHOD get_used_capacity.
    SELECT SUM( seatsocc + seatsocc_b + seatsocc_f )
      INTO @rv_used_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.

  METHOD get_total_capacity.
    SELECT SUM( seatsmax + seatsmax_b + seatsmax_f )
      INTO @rv_total_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.

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

  CREATE OBJECT o_airline_capacity.

  total_capacity = o_airline_capacity->get_total_capacity( 'AA' ).
  available_capacity = o_airline_capacity->get_available_capacity( 'AA' ).
  used_capacity = o_airline_capacity->get_used_capacity( 'AA' ).


  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.

You execute the program and the results look good.

As a skilled developer, you understand the importance of writing unit tests and ensuring the reliability of your code. Therefore, you also create a test class to validate your solution.

CLASS ltc_airline_capacity_tests DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.
  PRIVATE SECTION.
    DATA: lo_airline_capacity TYPE REF TO zcl_airline_capacity.

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

CLASS ltc_airline_capacity_tests IMPLEMENTATION.
  METHOD setup.
    CREATE OBJECT lo_airline_capacity.
  ENDMETHOD.

  METHOD test_get_available_capacity.
    DATA: lv_available_capacity TYPE i.

    lv_available_capacity = lo_airline_capacity->get_available_capacity( iv_carrid = 'AA' ).

    cl_abap_unit_assert=>assert_not_initial(
      act = lv_available_capacity
      msg = 'Available capacity for the airline should not be initial'
    ).
  ENDMETHOD.

  METHOD test_get_used_capacity.
    DATA: lv_used_capacity TYPE i.

    lv_used_capacity = lo_airline_capacity->get_used_capacity( iv_carrid = 'AA' ).

    cl_abap_unit_assert=>assert_not_initial(
      act = lv_used_capacity
      msg = 'Used capacity for the airline should not be initial'
    ).
  ENDMETHOD.

  METHOD test_get_total_capacity.
    DATA: lv_total_capacity TYPE i.

    lv_total_capacity = lo_airline_capacity->get_total_capacity( iv_carrid = 'AA' ).

    cl_abap_unit_assert=>assert_not_initial(
      act = lv_total_capacity
      msg = 'Total capacity for the airline should not be initial'
    ).
  ENDMETHOD.

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

    lv_available_capacity = lo_airline_capacity->get_available_capacity( iv_carrid = 'AA' ).
    lv_used_capacity = lo_airline_capacity->get_used_capacity( iv_carrid = 'AA' ).
    lv_total_capacity = lo_airline_capacity->get_total_capacity( iv_carrid = 'AA' ).

    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.

Change in Requirement

A few weeks later, Mary has a new request to modify the original requirement.

Can you update the program so that the available capacity calculation only considers economy class seats?

However, since you are currently occupied with a major project, another developer, Ali, is assigned to handle this feature request. They believe it's a straightforward change and proceed to update the get_available_capacity method accordingly.

  METHOD get_available_capacity.
    SELECT SUM( seatsmax - seatsocc )
       INTO @rv_available_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.

Ali executes the program and the results look good. Except they are wrong!

The available capacity value is lower than before, but the used and total capacity did not change. This is because those two other calculations still include business and first-class seats.

However, Ali knows that the CI pipeline will automatically run unit tests so he runs then locally. He notices there's an error - "Total capacity should be equal to the sum of available and used capacity".

Upon closer inspection Ali realizes that the code is now inconsistent. Available capacity is based on economy but used and total is for all seat types, economy, business, and first.

Ali assumes Mary meant to update the code to only look at economy class for all values. But instead of just making an assumption, Ali calls Mary and explains the inconsistency and asks her how to proceed. Mary confirms that she wants only the values for economy fares for all calculations.

Ali then updates the code and runs the test again. He also adds a helpful comment. Specifically, Ali updated the get_available_capacity, get_used_capacity, and get_total_capacity methods to consider only economy class seats, ensuring consistency across all calculations.

  METHOD get_available_capacity.
    " Only consider economy
    SELECT SUM( seatsmax - seatsocc )
       INTO @rv_available_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.

  METHOD get_used_capacity.
    " Only consider economy
    SELECT SUM( seatsocc )
      INTO @rv_used_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.

  METHOD get_total_capacity.
    " Only consider economy
    SELECT SUM( seatsmax )
      INTO @rv_total_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.

The results look and are correct.

Ali confirms they are correct by running the ABAP Unit tests.

Ali then moves this code to the central landscape and to QA for Mary to test. He knows with a high degree of confidence that this code will be moved to production.

To access the complete codebase, please visit the following GitHub repository: nuve-platform/sflight-demo

Key Takeaways

Unit testing is an essential part of modern software development, and ABAP is no exception. By incorporating unit tests into your development process, you can ensure that your code remains robust, adaptable, and less prone to errors. This is a simple example that highlights how easy it is to start introducing bugs to your code. In the real-world, programs are often more complex and by not catching errors early you are slowing down the business and increasing the true cost of development.

With the help of tools like ABAP Unit and continuous integration, you can build a solid foundation for your SAP applications, making it easier to adapt to ever-changing requirements and maintain high-quality code.

Now that you understand the power of unit testing in ABAP, it's time to start incorporating it into your development process. By doing so, you'll not only improve your skills but also contribute to a more reliable and robust SAP ecosystem.

Happy testing!