Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
christianjsosa
Participant
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: