从生成骨架到可维护测试,深入理解 CDS Unit Test 测试类结构的精炼过程 在 ADT 里通过向导为一个 CDS View Entity 创建 ABAP Unit Test 时,系统很快就能生成一套看起来已经相当完整的测试类。类定义有了,class_setup、setup、class_teardown也有了,CL_CDS_TEST_ENVIRONMENT已经出现,甚至连执行 CDS 查询的SELECT语句都准备好了。但生成测试类骨架和得到一套真正适合长期维护的单元测试,中间还有一段很关键的工作。SAP Flight Reference Scenario 中的/DMO/I_FLIGHT_R正好展示了这一步。我们面对的不是一个普通 ABAP 类方法,而是一个 CDS View Entity。它的业务逻辑最终运行在数据库层,可能包含字段计算、CASE表达式、关联、路径表达式以及对底层表和其他 CDS Entity 的依赖。传统的 ABAP Mock 思路并不能简单地把这些数据库依赖替换掉,所以 SAP 提供了 CDS Test Double Framework,让测试代码可以在数据库层为 CDS 的依赖创建替身。SAP 官方对这个框架的定位也很明确,CDS Test Double Framework 会为 CDS 的依赖组件创建可更新的 Test Double,让被测 CDS 在执行时读取我们准备的测试数据,而不是依赖生产数据库中的真实业务数据。被测 CDS 自身并不会因为测试而被修改。因此,这一阶段真正要解决的问题不是怎样把更多代码塞进测试类,而是怎样把向导生成的通