ABAP Units in ABAP RESTful Programming Model

Objective and Advantages of writing ABAP Units

1. ABAP units helps in testing an individual and independent unit of code without the availability/need of full application.
   
2. Testing can be done even if fields are not exposed in UI and UI application is not available.
   
3. Mock data is created in ABAP units which means that the actual data which is in tables is not modified. So, you can test on same data multiple times without any locking issues and prevent data inconsistency in actual data. This is achieved by creating test double environment.
   
4. ABAP units are transported from development system till the production system. So, you can run the ABAP units on production system as well without modifying actual production data to test individual units of code. This is very helpful in case of incident resolution where we can’t change production data but we need to debug and analyze the root cause.
   
5. Few ABAP objects such as instance methods of class cannot be directly executed (independently) in SAP. With the help of ABAP units, you can execute and test these independent units of code.

Setup and Creation of ABAP Unit Test Doubles

In behavior implementation class, navigate to test classes section and type “test” and then press ctrl+space. Select “testClass” and press enter.

Provide test class name. For our e.g. we will test class name as “ltcl_scarr”.

As implementation methods for determinations, validations and actions are private methods of behavior implementation class, we will have to make our test class as friend class of behavior implementation class so that we can call private implementation methods inside our test class.

Now we will create the test double environment for our entities and tables. This will be done in setup and teardown methods of test class. Test double environment for entities will be created using interface “if_cds_test_environment” and for tables apart from the tables in entities such as customizing tables or any other tables from which we will be selecting data in implementation methods, we will use interface “if_osql_test_environment”.

In the above test class, we have created test double environment for parent entity “SCARR” and it’s child entity “BOOKING”. We have also created test double environment for table “EKPO”. Here, we have used the consumption and TP layer for creating test double environment, but you can also use TP and basic layer. But, in this case you may not be able to access extended fields from extension view of these entities.

ABAP Units for determination, validation and action in ABAP RESTful Programming Model (RAP)

Now, we will create unit test method for a determination “setBookingTime” in which we will be determining the booking time.

Now, we will create unit test method for a validation “checkBookingTime” in which we will check if the booking time is not initial.

Now, we will create unit test method for a action “markComplete” in which we will mark the current booking as completed.

Handle draft cases in ABAP RESTful Programming Model (RAP)

The above cases will prepare mock data for active tables only and won’t work with the draft tables. There can be some cases where we explicitly need to check if the draft (%is_draft) is on, then only perform the operation. In this case we will use the “Edit” action to create draft for our mock data and then use rollback in teardown method to rollback all the changes.

Common mistakes which we make while writing ABAP units

1. We skip the creation of test doubles in ABAP units and pass the keys directly from actual tables while testing in development and testing environment. In this case, when ABAP units are executed, as the records are there in development and testing environment and keys are valid, it reads data from actual tables and performs action on actual data. Please refrain from passing actual table keys in ABAP units from development and testing environment. If we do so, we will face following issues:
   
   • You will be able to test the complete functionality in development and test environment and then the code is transported to integration/quality environment before transporting to production environment. You won’t be able to test the ABAP units in integration/quality environment as the keys don’t exists.
     
   • In integration/quality environment as the keys don’t exists, most of the ABAP units will fail which will result in ATC warnings.
     
2. We usually provide only one test case while writing ABAP units. Make sure if there are various conditions in your code such as if/case statements, then provide multiple test cases for each condition and loop the method call for each test case. The idea behind this is to have the maximum possible code coverage percentage. In production environment, you will have restricted debugging access. You won’t be able to use functions such as go to statement and edit variable values. If code coverage percentage is low, then you won’t be able to test most of the code in production and won’t be analyze the root cause of the incident.
   
3. We skip the call of standard ABAP unit methods such as assert_equals, assert_initial, etc of class “cl_abap_unit_assert”. These methods compares the actual values with the expected values. Skipping these methods will always result in successful execution of ABAP units even if your expected and actual results are not same.
   
4. We pass the same variable in expected and actual results in standard ABAP unit methods such as assert_equals which will always result in successful execution of ABAP units even if your expected and actual results are not same.
   
5. We use statements such as “commit work” or “commit entities” in their ABAP unit methods. Refrain from using these statements and you always work on mock data and you are not trying to change the actual data in tables. Instead use “rollback” or “rollback entities” to rollback all the changes done in ABAP units. This can be done in teardown method.