CDS测试框架介绍:如何为ABAP CDS Entities写测试

动机

现在大家都知道单元测试对我们代码的好处。并且我们都承认它是开发过程中不可或缺的一部分。但是在把代码切换到数据库的模式下的时候,我们被粗暴地打回了软件测试的黑暗年代...我们现在面临着逻辑下推到ABAP CDS entities后,代码要如何测试的难题。

CDS Test Double Framework允许开发者们通过众所周知的ABAP Unit Test Framework自动化地测试CDS entities。

本文链接:http://www.cnblogs.com/hhelibeb/p/7376232.html

英文原文:Introduction to CDS Test Double Framework – How to write unit tests for ABAP CDS Entities?

挑战

因为CDS entity中的逻辑运行在下层的数据库中(独立于abap runtime),使用传统的ABAP依赖注入解决方案以实现测试成为了不可能的事情。entity的依赖组件需要在数据库中加上测试替身,并且我们必须确保CDS entity测试的时候数据库引擎调用/执行这些测试替身(double)。

为了可以在CDS entity under test (CUT)中可控地测试逻辑,我们需要通过测试替身注射测试专用数据。这意味着必须将测试数据插入到测试替身中,这样数据可以在CUT执行时被测试替身们返回。对于在ABAP CDS上下文中有着固有的只读属性的依赖组件(比如数据库视图和数据库函数),这是一项特别的挑战。

本文中重要的缩写:

CUT = CDS entity Under Test

DOC = Depended-On Component

CDS Test Double Framework

CDS Test Double Framework处理了以上的挑战,并且可以实现CDS entities测试的自动化:

  1. 在相同的Database Schema中为每个依赖组件创建临时的可更新测试替身

    1. 复制依赖组件表,但不复制任何数据。不复制依赖数据库表的主键约束。这允许你轻松地插入测试数据,而不用担心数据的完整性。相似的,数据库索引也不会被复制。
    2. 为依赖数据库视图创建数据库表。这些表有着和依赖数据库视图相同的结构。
    3. 依赖数据库functions(由带有参数的依赖CDS视图和依赖表function产生)会被复制,并且function的测试替身实现会被修改为允许插入需要的测试数据。
  2. 在相同的Database Schema创建一个CDS entity under test(CUT)的临时副本。从各种意义上来看,这个副本是为CUT服务的。在原始的CDS entity中实现的逻辑在副本中同样存在,但是依赖组件被替换为了相应的测试替身。测试替身是由我们的CDS Test Double Framework所创建的。

测试什么?

单元测试应当专注于由一个给定视图实现的有价值的功能定义。不是所有的CDS视图都需要一个单元测试。在实现单元测试之前,建议辨别出entity中与测试有关的方面。

通常,需要为某些包含了代码下推的方法的entity进行单元测试。潜在的测试候选者包括:

Calculations and/or filters, conversions, conditional expressions 比如 CASE…THEN…ELSE or COALESCE, type changing CAST operations, cardinality changes or checks against NULL values,  JOIN behavior, complex where conditions 等.

单元测试不应用于测试那些更适用于静态检查、集成测试等技术的CDS entities属性。如果不能从单元测试中获取任何价值的话,也不应进行它,比如对于那些简单的CDS投影视图。

怎样使用CDS Test Double Framework写单元测试?

在下一部分,我们会通过被广泛应用的ABAP Unit Test Framework为以下的CDS视图创建单元测试。

@AbapCatalog.sqlViewName: ‘zSo_Items_By_1‘
@EndUserText.label: ‘Aggregations/functions in SELECT list‘
@AbapCatalog.compiler.compareFilter: true
define view Salesorder_Items_By_TaxRate
as select from CdsFrwk_Sales_Order_Item
association [1] to snwd_so as _sales_order on so_guid = _sales_order.node_key
{
so_guid,
coalesce ( _sales_order.so_id, ‘9999999999‘ ) as so_id,
currency_code,
sum( gross_amount ) as sum_gross_amount,
tax_rate,
_sales_order
}
group by
so_guid,
_sales_order.so_id,
currency_code,
tax_rate

创建ABAP测试类

创建一个ABAP测试类以对CDS视图进行单元测试。有一个好的实践方法:为测试类起一个和CUT相同/相似的名字,并且加上TEST的后缀。比如,对于CDS视图Salesorder_Items_By_TaxRate,测试类的名字可以是:Salesorder_Items_By_TaxRate_Test.

因为单元测试和CDS是不同的东西,相同/相似的名字可以帮助我们轻松的寻找相关的测试。

CLASS Salesorder_Items_By_TaxRate_Test DEFINITION FINAL FOR TESTING
DURATION SHORT
RISK LEVEL HARMLESS.
PRIVATE SECTION.
...
...
ENDCLASS.

CLASS SO_ITEMS_BY_TAXRATE_TEST IMPLEMENTATION.
...
...
ENDCLASS.

定义固定方法

定义以下的安装拆卸方法。

运行方法cl_cds_test_environment=>create( i_for_entity = ‘<CDS under test>’ ),隐式地在数据库中创建所有依赖组件测试替身。这个方法在测试类中只应被调用一次。

"Fixture method class_setup is executed only once in the beginning of the execution of test class
METHOD class_setup.
"For parameter i_for_entity, specify the CDS view to be unit tested. This will create all the depended-on component Test doubles in the database.
environment = cl_cds_test_environment=>create( i_for_entity = ‘Salesorder_Items_By_TaxRate‘ ).
ENDMETHOD.

METHOD class_teardown.
environment->destroy( ).
ENDMETHOD.

"Fixture method setup is executed once before each test method execution
<cod
METHOD setup.
environment->clear_doubles( ).
ENDMETHOD.

定义单元测试方法

METHOD cuco_1_taxrate_1_item_1_ok.

ENDMETHOD.

准备输入——在测试替身中插入测试数据

METHOD cuco_1_taxrate_1_item_1_ok.

"Step 1 : Insert testdata into the doubles
"Step 1.1 : create an instance of type snwd_so. Note : CDS view Salesorder_Items_By_TaxRate depends on snwd_so.
sales_orders = VALUE #( ( client = sy-mandt node_key = ‘01‘ so_id = ‘ID‘ ) ).

"Step 1.2 : Use the framework method CL_CDS_TEST_DATA=>create(..) to create the test_data object
test_data = cl_cds_test_data=>create( i_data = sales_orders ).

"Step 1.3 : Use the framework method environment->get_double(..) to create the instance of the double ‘SNWD_SO‘
DATA(sales_orders_double) = environment->get_double( i_name = ‘SNWD_SO‘ ).

"Step 1.4 : Insert the testdata into the double depended-on component object
sales_orders_double->insert( test_data ).

"Repeat Step 1 for all the depended-on component doubles
sales_order_items = VALUE #( ( mandt = sy-mandt so_guid = ‘01‘ currency_code = ‘EUR‘ gross_amount = ‘1‘ tax_rate = ‘19.00‘ ) ).
test_data = cl_cds_test_data=>create( i_data = sales_order_items ).
DATA(sales_order_items_double) = environment->get_double( i_name = ‘CdsFrwk_DEMO_1‘ ).
sales_order_items_double->insert( test_data ).

...

ENDMETHOD.

执行CDS

SELECT * FROM cdsfrwk_so_items_by_taxrate INTO TABLE @act_results.

验证输出——使用ABAP单元测试的断言

exp_results = VALUE #( ( so_id = ‘ID‘ currency_code = ‘EUR‘ sum_gross_amount = ‘1‘ tax_rate = ‘19.00‘ ) ).
cl_abap_unit_assert=>assert_equals(
act = lines( act_results )
exp = lines( exp_results ) ).

"The method looks as follows:

METHOD cuco_1_taxrate_1_item_1_ok.

"Step 1 : Insert testdata into the doubles
"Step 1.1 : create an instance of type snwd_so
sales_orders = VALUE #( ( client = sy-mandt node_key = ‘01‘ so_id = ‘ID‘ ) ).

"Step 1.2 : Use the framework method CL_CDS_TEST_DATA=>create to create the test_data object
test_data = cl_cds_test_data=>create( i_data = sales_orders ).

"Step 1.3 : Use the framework method environment->get_double to the instance of the DOC double ‘SNWD_SO‘
DATA(sales_orders_double) = environment->get_double( i_name = ‘SNWD_SO‘ ).

"Step 1.4 : Insert the testdata into the DOC double object
sales_orders_double->insert( test_data ).

"Repeat Step 1 for all the DOC doubles
sales_order_items = VALUE #( ( mandt = sy-mandt so_guid = ‘01‘ currency_code = ‘EUR‘ gross_amount = ‘1‘ tax_rate = ‘19.00‘ ) ).
test_data = cl_cds_test_data=>create( i_data = sales_order_items ).
DATA(sales_order_items_double) = environment->get_double( i_name = ‘CdsFrwk_DEMO_1‘ ).
sales_order_items_double->insert( test_data ).

"Step 2 : Execute the CDS
SELECT * FROM cdsfrwk_so_items_by_taxrate INTO TABLE @act_results.

"Step 3 : Verify Expected Output
exp_results = VALUE #( ( so_id = ‘ID‘ currency_code = ‘EUR‘ sum_gross_amount = ‘1‘ tax_rate = ‘19.00‘ ) ).
assert_so_items_by_taxrate( exp_results = exp_results ).

ENDMETHOD.

运行CDS的单元测试

ADT当中,打开包含所有CDS单元测试的ABAP测试类。右键选择Run As->ABAP Unit Test,或者使用ctrl+shift+f10组合键来运行单元测试。结果会在eclipse中的ABAP Unit Runner视图中显示。

注意:至今为止,还不能在DDL源代码编辑器中直接运行单元测试。

受支持的测试场景

CDS Test Double framework支持为给定的CUT的以下DOC创建测试替身:

  • DDIC tables
  • DDIC views
  • CDS views
  • CDS views with Parameters
  • External Views
  • Table Functions
  • CDS special functions. CURRENCY_CONVERSION and UNIT_CONVERSION

你可以打开/关闭给定CDS的DCL,更多细节会在本文的后面提供。

依赖组件是Table Function

Tables Function的测试替身的操纵方式和其它的CDS视图一样。

依赖组件是带有参数的CDS视图

CDS Test Double Framework提供了

cl_cds_test_data=>create( .. )->for_parameters( .. )

来为带有参数的类型的测试替身插入数据。

METHOD eur_tax_rate_19_found.

"Step 1 : Insert testdata into the doubles
open_items = VALUE #( ( mandt = sy-mandt so_guid = ‘0F‘ tax_rate = ‘19.00‘ so_id = ‘1‘ ) ).
i_param_vals = VALUE #( ( parm_name = `pCuCo` parm_value = `EUR` ) ).

"CdsFrwk_demo_3 is a CDS view with parameters. Use framework method ->for_parameters( ) to insert test data
test_data = cl_cds_test_data=>create( i_data = open_items )->for_parameters( i_param_vals ).

DATA(open_items_double) = environment->get_double( ‘CdsFrwk_demo_3‘ ).
open_items_double->insert( test_data ).

...
...
ENDMETHOD.

DCL对CUT的影响

你也可以打开/关闭给定的CDS的DCL。但是,在目前,如果你的CDS DDL在测试时受到DCL影响的话,我们建议在运行测试时总是关闭DCL。在未来,使用DCL时会有很多选项可以玩,并且可以使用角色权限测试替身等。但是在目前的版本中,你需要注意在测试CDS DDL时完全关闭DCL(如果有的话)。在打开DCL时些测试可能导致测试间断性失败,因为实际访问控制角色权限会被应用。因此,建议在你的生产测试中总是有一个:

DISABLE_DCL=ABAP_TRUE in the cl_cds_test_environment=>create(…)

对特殊function的支持:CURRENCY_CONVERSION和UNIT_CONVERSION

CDS Test Double framework中可以为两个特殊的CDS function提供支持:

"Step 1 : Create testdata using the special framework method create_currency_conv_data
test_data = cl_cds_test_data=>create_currency_conv_data( output = ‘399.21‘ )->for_parameters(
amount = ‘558.14‘
source_currency = ‘USD‘
target_currency = ‘EUR‘
exchange_rate_date = ‘20150218‘
).

"Step 2 : Get the double instance using the framework method get_double
DATA(curr_conv_data_double) = environment->get_double( cl_cds_test_environment=>currency_conversion ).

"Step 3 : Insert test_data into the double
curr_conv_data_double->insert( test_data ).

带有NULL值的测试

为了在测试替身中插入null值,CDS Test Double Framework提供了方法:

cl_cds_test_data=>create( .. )->set_null_values( .. )

该方法可以显式地设定null值。

partners = VALUE #( ( client = sy-mandt bp_id = ‘1‘ ) ).

"Step 1 : define the list of columns into which NULL is inserted
i_null_vals = VALUE #( ( `address_guid` ) ).

"Step 2 : Create testdata and set the NULL value object
test_data = cl_cds_test_data=>create( i_data = partners )->set_null_values( i_null_vals ).

"Step 3 : Get test Double instance
DATA(partners_double) = environment->get_double( i_name = ‘SNWD_BPA‘ ).

"Step 4 : Insert test data into test double
partners_double->insert( test_data ).

Demo examples

你可以在这个包里找到许多单元测试的例子:

SABP_UNIT_DOUBLE_CDS_DEMO

可用性

CDS Test Double Framework从NetWeaver AS ABAP 7.51 release开始可用。

更多信息

报告bug的话,请为CSS组件BC-DWB-TOO-UT-CDS创建tickets。

总结:通过本文,你现在可以使用CDS Test Double Framework高效地为你在CDS中实现的代码下推来写自动化的测试!

时间: 2024-10-12 01:38:02

CDS测试框架介绍:如何为ABAP CDS Entities写测试的相关文章

python pytest测试框架介绍三

之前介绍了pytest以xUnit形式来写用例,下面来介绍pytest特有的方式来写用例 1.pytest fixture实例1 代码如下 from __future__ import print_function import pytest @pytest.fixture(scope='module') def resource_a_setup(request): print('\nresources_a_setup()') def resource_a_teardown(): print('

python pytest测试框架介绍四----pytest-html插件html带错误截图及失败重测机制

一.html报告错误截图 这次介绍pytest第三方插件pytest-html 这里不介绍怎么使用,因为怎么使用网上已经很多了,这里给个地址给大家参考,pytest-html生成html报告 今天在这里介绍pytest生成的报告怎么带有截图,这在web自动化测试非常有用. 需求是测试用例错误就截图,方法如下: 我们要新建一个关于截图的插件文件conftest.py,注意,文件名不能变,因为pytest-html会自动找这个自己写的插件,内容如下: from selenium import web

pytest测试框架介绍(3)

12.fixture带参数传递 场景:测试离不开数据,为了数据灵活,一般数据都是通过参数传的 解决:fixture通过固定参数request传递: 步骤:在fixture中增加@pytest.fixture(params=[1,2,3,'linda'])在方法参数写request 如下图,运行结果: 参数传入的可以是列表是元祖 如下图,eval将字符串str当成有效的表达式来求值,并返回结果: 当我们测试登录或者搜索这种同样的场景需要不同的数据时,就可以使用这种参数组合的方法: 运行结果如下:

python pytest测试框架介绍五---日志实时输出

同样的,在使用pytest进行自动化测试时,需要将实时日志打印出来,而不是跑完后才在报告中出结果. 不过,好在pytest在3.3版本开始,就支持这一功能了,而不用再像nose一样,再去装第三方插件. 网上也有相关实时的日志输入说明,但我尝试后,不是我想要的,比如:pytest输出Log 看看我们下面这样一段代码,以unittest模式写的: #coding:utf-8 ''' Created on 2017年8月31日 @author: huzq ''' from __future__ imp

Java Junit测试框架

Java    Junit测试框架 1.相关概念 ? JUnit:是一个开发源代码的Java测试框架,用于编写和运行可重复的测试.它是用于单元测试框架体系xUnit的一个实例(用于java语言).主要用于白盒测试,回归测试. ? 白盒测试:把测试对象看作一个打开的盒子,程序内部的逻辑结构和其他信息对测试人 员是公开的. ? 回归测试:软件或环境的修复或更正后的再测试,自动测试工具对这类测试尤其有用. ? 单元测试:最小粒度的测试,以测试某个功能或代码块.一般由程序员来做,因为它需要知道内部程序设

Android开源测试框架学习

近期因工作需要,分析了一些Android的测试框架,在这也分享下整理完的资料. Android测试大致分三大块: 代码层测试 用户操作模拟,功能测试 安装部署及稳定性测试 代码层测试 对于一般java代码,采用传统的Junit测试,开发人员通常会编写重要接口和函数的白盒测试代码,不做过多讨论. 但因Android的特殊运行机制(Dalvik虚拟机),其中存在Application.Activity.Service等特殊组件,而这些组件都涉及到生命周期管理的问题. 为了对这些组件进行测试,Goog

前端测试框架

一.为什么要进行测试? 一个 bug 被隐藏的时间越长,修复这个 bug 的代价就越大.大量的研究数据指出:最后才修改一个 bug 的代价是在 bug 产生时修改它的代价的10倍.所以要防患于未然. 从语言的角度讲 JavaScript 作为 web 端使用最广泛的编程语言,它是动态语言,缺乏静态类型检查,所以在代码编译期间,很难发现像变量名写错,调用不存在的方法, 赋值或传值的类型错误等错误. 例如下面的例子, 这种类型不符的情况在代码中非常容易发生 function foo(x) { ret

Pytest框架介绍

Pytest框架介绍.安装 pytest是python测试框架,与python自带的unittest测试框架类似,但是比unittest框架使用起来更简洁,功能更强大 pytest特征 1:断言提示信息更清楚 2:自动化加载函数与模块 3:支持运行由nose, unittest编写的测试case 4:支持py2.3,2.7,3.x 5:丰富的插件以及社区支持 6:支持参数化 7:支持失败重跑 8:支持多线程跑用例 9:支持分布式 pytest安装 pip安装,在cmd下面执行命令 pip ins

[android] android下junit测试框架配置

我们的业务代码一般是放在一个新的包下面,这个业务类不能够通过右键run as java application,因为android项目只能运行在手机上的dalvak虚拟机里面 新建一个包,里面写测试类,测试类需要继承AndroidTestCase类,写测试方法,需要throws exception抛出异常给测试框架,测试方法里面一般new出需测试的类,调用它的方法,然后断言结果,assertEquals(预估, 实际结果) 在outline视窗 (window=>show view=>outl