SAP defines Test-Driven Development (TDD) as “a way to develop software driven by automated tests which are written earlier than the production code itself”[1]

Applying this approach for AMDPs is particularly challenging since there are no built-in tools for mocking database tables within AMDPs (unlike regular ABAP classes, where cds views and database tables can be mocked through classes cl_cds_test_environment() and cl_osql_test_environment() respectively)

Requirement

Data needs to be selected from HANA native artifacts (either tables or calculation views) with complex selection criteria. Since artifacts are not available within the ABAP dictionary, AMDPs need to be used. The best way to ensure correctness is by establishing testcases the AMDP must fulfill.

The test cases must be runnable automatically and must be independent of the database contents. This ensures that testcases are runnable and robust across systems.

Solution

Identify input parameters and HANA native artifacts needed by the method

et_result = SELECT a.field_a, a.field_b, b.field_c,
    FROM y_table_a AS a
    LEFT OUTER JOIN y_table_b AS b ON a.field_a = b.fk_field_a
    WHERE a.field_d = :iv_param

Expose such parameters (including tables) as IMPORTING parameters within the AMDP

y_table_a -> lt_table_a
y_table_b -> lt_table_b
iv_param

Expose the returning set of the AMDP as EXPORTING tables

et_result

Implement unit tests

This is done by defining mockdata as input, calling the function under test and performing assertions on the returned values

Eclipse provides a very useful tool to extract mockdata from a development system’s table:

Exporting VALUE #() statements from Eclipse

Implement the actual business logic

Selection must be performed based on the parameterized tables and not the actual HANA tables:

et_result = SELECT a.field_a, a.field_b, b.field_c,
    FROM :it_table_a AS a
    LEFT OUTER JOIN :it_table_b AS b ON a.field_a = b.fk_field_a
    WHERE a.field_d = :iv_param

Run tests again and iterate until all tests are successful. Should new requirements be identified, then tests might need to be changed accordingly.

Caveats

Since tables for selection are given as parameters, the result set should ideally be filtered early on to prevent memory leaks. This means, that some WHERE-Conditions must be placed outside of the testable method, so they remain outside the testable scope.

By using this approach, the passing of parameters is potentially very memory intensive. This limits its applicability to cases where the datasets are small.

Resources

The following resources were useful for this analysis:

• [1] Test-Driven Development for ABAP:  https://help.sap.com/docs/BTP/5371047f1273405bb46725a417f95433/4ec2efe26e391014adc9fffe4e204223.html?locale=en-US
• [2] Dependency injection for AMDPs: https://www.brandeis.de/blog/wiederverwendung-von-geschaeftslogik-in-amdp-transformationsroutinen