功能写完才补测试，这件事在 RAP 项目里通常会很被动做过事务型服务的人都知道，一个Create动作落地到系统里，往往不只是把一行数据写进表那么简单。它背后可能牵着 determination、validation、action、副作用读写，甚至还会顺手触发 business event。你在界面上看到只是点一下保存，到了后端，其实已经穿过了 data model、behavior implementation、EML、OData 暴露层，最后才形成完整的业务结果。也正因为这一串链路很长，测试如果只停留在程序能跑这个层面，后面一改字段推导逻辑，或者多加一条校验规则，回归问题就会一串串冒出来。SAP 在官方文档里把Develop Tests单独抽成一个章节，不是为了把测试做成附属品，而是把它当成 ABAP Cloud 交付闭环里不可拆开的组成部分。官方也明确把测试和代码质量、ATC、UI 测试放在同一条质量链条里来看。再往深一点看，ABAP Cloud 给测试这块准备的，不只是一个ABAP Unit。官方文档强调，隔离测试的目标，是让错误可以被稳定复现，让回归原因能被快速定位，同时避免测试准备阶段引入额外副作用。围绕这个目标，SAP 在 ADT 里提供了多种 test double framework，覆盖 SQL、CDS、RAP BO、RAP Event、ABAP OO 以及 Test Seams，不同框架分别对应数据库依赖、CDS 实体依赖、EML 依赖、事件依赖和对象依赖。这个设计很有意思，它不是让你写一个万能大测试，而是鼓励你把测试颗粒度切开，哪个层面出问题，就在哪个