乐趣区

关于sap:SAP-CDS-view单元测试框架Test-Double介绍

jiezi

系列目录

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

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

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.

要获取更多 Jerry 的原创文章，请关注公众号 ” 汪子熙 ”:

退出移动版