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. 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: