系列目录
Part1 – how to test odata service generated by CDS view
Part2 – what objects are automatically generate after you activate one CDS view
Part3 – how is view source in Eclipse converted to ABAP view in the backend
Part4 – how does annotation @OData.publish work
Part5 – how to create CDS view which supports navigation in OData service
Part6 – consume table function in CDS view
Part7 – unveil the secret of @ObjectModel.readOnly
Part8 – my summary of different approaches for annotation declaration and generation
Part9 – cube view and query view
Part10 – How does CDS view key user extensibility work in S4
Part11 – this blog
Part12 – CDS view source code count tool
Part13 – CDS view authorization
Part14 – CDS view performance analysis using PlanViz in HANA studio
There is a wonderful blog Introduction to CDS Test Double Framework – How to write unit tests for ABAP CDS Entities? written by Sunil Bandameedapalli.
For me, the CDS view test double framework works as a magic for me: how the mocked data I inserted into the view under test could be read again in unit test code? As a result in this blog I will try to explain how CDS view framework works under the hood.
The view I am developed is listed below, which is simply used to return material guid with description by joining table MAKT with MARA:
Create a new class and you do not need to create any method within this class.
Activate the class and perform unit test, you should see the information message that unit test is successfully executed.
Now let’s see how the whole scenario works.
Step1 – Test environment creation
This is done in CLASS_SETUP method:
cl_cds_test_environment=>create( i_for_entity =’PRODUCTSHORTTEXT’ ).
From the CASE-WHEN statement below we can know that the CDS test framework still supports various Database other than HANA.
Step2 – CDS view source code parse
The framework should know which database tables are used in the CDS view under test, since the mock data is inserted to database table level, not CDS view level.
The source code parse is done via a Visitor pattern and result stored in r_result, which contains two table, MARA and MAKT of course.
If you would like to know how this Visitor pattern works in detail, please refer to my blog Visitor pattern used in CDS View Test double framework.
Step3 – Created transient tables based on parsed database table
Since the test double framework knows from step2 that MARA and MAKT are involved in the CDS view under test, so now it is able to create transient tables based on both. The created tables are dummy, which is used to hold test data inserted in the unit test, and those dummy tables will be destroyed when the test environment is destroyed, I would like to call them as shadow table.
Step4 – unit test developers insert test data to shadow table
Unit test developers now prepare test data, wrap it by calling cl_cds_test_data=>create, and insert the wrapped test data into shadow table via API insert provided by test double framework.
In next step when the CDS view under test is queried in unit test code, the inserted data prepared in this step will be serving as response.
Step5 – OPEN SQL redirected to shadow table
When the CDS view is queried, the read operation will be actually redirected to shadow table created in step 3.
And how CDS test double framework knows which shadow table should be redirected for MARA and which for MAKT?
Actually in step3, when shadow table are created, the relationship between original table and created shadow table are maintained in an internal table:
Based on this metadata, the real redirection is switched on by a Kernel implementation:
Update on 2017-04-25 15:39PM
I remove the explanation on how the kernel module mentioned above is implemented as my ABAP colleague tells me it should not be published to the public.
