Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
Showing results for 
Search instead for 
Did you mean: 

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:
@AbapCatalog.sqlViewName: 'PRODSHTEXT'
@VDM.viewType: #BASIC
@AccessControl.authorizationCheck: #NOT_REQUIRED
@ClientHandling.algorithm: #SESSION_VARIABLE
@EndUserText.label: 'Product Description'
define view ProductShortText
as select from makt
inner join mara on makt.matnr = mara.matnr
key mara.scm_matid_guid16 as ProductGuid,
key makt.spras as Language,
makt.maktx as ProductName,
makt.maktg as ProductNameLarge

Create a new class and you do not need to create any method within this class. Click tab "Local Test Classes", and paste the source code from here.

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.