A Test-Driven Approach for developing AMDPs
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”
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)
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.
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
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:
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.
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.
The following resources were useful for this analysis:
-  Test-Driven Development for ABAP: https://help.sap.com/docs/BTP/5371047f1273405bb46725a417f95433/4ec2efe26e391014adc9fffe4e204223.html?locale=en-US
-  Dependency injection for AMDPs: https://www.brandeis.de/blog/wiederverwendung-von-geschaeftslogik-in-amdp-transformationsroutinen