- SAP Managed Tags:
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)
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.
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:
Selection must be performed based on the parameterized tables and not the actual HANA tables:
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:
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_resultImplement 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...
- [2] Dependency injection for AMDPs: https://www.brandeis.de/blog/wiederverwendung-von-geschaeftslogik-in-amdp-transformationsroutinen
| User | Count |
|---|---|
| 17 | |
| 8 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
