ABAP Unit - Tips
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.
Table of contents
For the writing of testable code and the navigation among the test objects, a few tips and tricks are shown in this article for better handling of the test cases.
Linking
As you have already seen in the chapter with the CDS Double, a separate class is created for the object and marked as a test class. However, this object is not connected to the Core Data Service and is not tested together with the object. To test the object, the entire package must be tested.
When executing the test on the object, the following message appears:
For this circumstance, the test class can be told which object is currently being tested and what the dependent objects are. To do this, we use ABAP Doc and use it to store our object in the test class. In addition the changed code of the test class definition:
"! @testing ZBS_C_COMPLETETOOLS
CLASS ltc_cds_access DEFINITION FINAL FOR TESTING
DURATION SHORT
RISK LEVEL HARMLESS.
PRIVATE SECTION.
CLASS-DATA:
go_environment TYPE REF TO if_cds_test_environment.
CLASS-METHODS:
class_setup RAISING cx_static_check,
class_teardown.
METHODS:
totalvalue_calculation FOR TESTING,
missing_text FOR TESTING,
dataset_count FOR TESTING.
ENDCLASS.
The ABAP Doc comment with @testing and the following object (note capitalization) must be added. The test class is now connected to the Core Data Service and if you run the unit test directly for it, you will get a result.
The test is displayed as a “Foreign Test” because it is not located directly on the object. At this point you also have the option to mark individual methods if you are testing different objects in a test class. Theoretically, each method can then be linked to a different object. However, we recommend that you create a test class for each object in order to separate the tests clearly from each other.
Eclipse Shortcuts
For more efficient work in Eclipse with unit tests and faster execution of the tests during development, we recommend using the shortcuts. These are easy to remember and will speed up your development. Shortcuts can be called in Eclipse in the current object, then only tests of this object are taken into account or you use them in the Project Explorer and can therefore also test via packages.
Preview
The preview is started with CTRL + SHIFT + F9 and does not run a unit test in the first step, but examines the objects for tests that can be carried out and displays them. As an example, we ran the preview once for an entire package.
The objects with the corresponding test classes and test methods are displayed. Right-clicking on the various nodes gives you the option of starting individual or all tests. You can also use the various methods (coverage and trace) here.
Execution
If you don't need a preview, you can start all tests of the object or the package directly with CTRL + SHIFT + F10. Execution starts and the test result is displayed.
Coverage
With CTRL + SHIFT + F11 you start the unit test with coverage measurement and can check how much of your source code is already covered with test cases. However, this form of execution takes a little longer than a simple unit test.
Settings
Before a function is even started, you have the option of specifying your settings with CTRL + SHIFT + F12. You can determine the various settings via the popup and then have the option to choose the preview or the execution.
Naming conventions
When naming the test classes and objects, some specialties have already been discussed. At this point we want to give suggestions as to what the individual test objects can be called:
- LCL_ - Local class / auxiliary class
- LTC_ - Local test class that contains the test cases
- LTD_ - Local test double that you need for your test cases
The delimitation of the different class names makes the use clear again and increases the readability for other colleagues, as they can immediately recognize the differences between the individual objects and what their purpose is.
Key topics
When developing your application, you should consider the following topics and integrate and/or provide them in your source code.
Constructor
- Don't work in the constructor
- Generate DOCs via Factory or Lazy Initialization
- Provision of injection mechanisms for your class
- Provide public interface via interfaces
An example of a lazy initialization could look like this:
CLASS zcl_bs_demo_double_class DEFINITION PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION.
DATA:
mo_uicomponent TYPE REF TO zif_test_display.
METHODS:
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 select_and_show_data.
SELECT *
FROM zbs_dy_tools
WHERE short_name = @id_short_name
INTO TABLE @DATA(lt_found_tools).
IF mo_uicomponent IS NOT BOUND.
mo_uicomponent = NEW zcl_test_display( ).
ENDIF.
rd_displayed = mo_uicomponent->display_generic_data( lt_found_tools ).
ENDMETHOD.
ENDCLASS.
You only create the instance of the component when you want to access it. This also gives you the opportunity to use the injection mechanism and to transfer and use your test double.
Static and global status
- Minimize dependencies on global data, variables and objects
- Encapsulation of the data in the class
- Use of the test double framework
- Use objects rather than static classes
SOLID
- Application of the SOLID principle when developing the software
- More information about SOLID on Wikipedia
Law of Demeter
- Keep dependencies between the objects to a minimum
- Restriction of the links and dependencies among the objects
Hint: Some of the methods described are standard procedures in software development and are no longer described in the course of this book. You can get more information on this from Wikipedia, for example, and find out more details there.
Conclusion
With this article, our series on the subject of ABAP Unit and how you can use it effectively and easily ends with you. There was a lot of input on the subject of testability of applications and the architecture, because most of the source codes are not yet ready for easy testability and have to be adapted. If you want to go deeper into the whole topic in one go, we recommend the complete book.
