在 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 自身并不会因为测试而被修改。因此，这一阶段真正要解决的问题不是怎样把更多代码塞进测试类，而是怎样把向导生成的通