如何在完全不持久化数据的情况下执行集成测试？关于OSQL Test Double Framework及持久层注入的技术问询

针对你遇到的「集成测试需要验证组件交互，但又不想产生持久化垃圾数据」的痛点，这里有两种可行的解决方案，结合你的业务场景（ZIF_MY_API和业务对象的联动测试）来具体说明：

方案一：用OSQL Test Double Framework全局拦截所有OSQL操作 #

你提到这个框架通常用来替换单个表，但其实它支持会话级的全局OSQL拦截，可以把所有数据库操作重定向到临时内存模拟层，完全绕过真实数据库的持久化。

具体操作步骤：

• 在测试类的SETUP方法中，启用全局OSQL替身：

  DATA(lo_test_double) = cl_osql_test_double=>create( ).
  lo_test_double->enable_session_wide( ).
  

• 为测试中涉及的所有表创建内存模拟表，或者定义通用的模拟规则：
  • 比如对所有INSERT/UPDATE/DELETE操作直接忽略（不写入真实数据库）；
  • 对SELECT操作预设你需要的测试数据，比如业务对象load_or_exception()需要的初始化状态数据。
• 测试结束后，在TEARDOWN方法中清理全局替身，避免影响其他测试：

  cl_osql_test_double=>destroy_all( ).
  

针对你的场景：测试ZIF_MY_API~start()和perform_send()的联动时，所有业务对象的数据库操作都会被拦截到内存中，你可以预设start()初始化后的状态数据，验证perform_send()能正常执行；也可以模拟未初始化的状态，验证直接调用perform_send()会抛出预期异常——全程不会产生任何持久化数据。

这种方案的优势是不需要修改生产代码，适合现有系统快速适配无持久化集成测试。

方案二：注入持久层接口（更优的长期架构方案） #

如果你的系统有重构空间，推荐从架构层面解决问题：把所有持久化操作封装到专门的持久层接口中，让业务逻辑依赖接口而非具体的数据库实现，这样在测试时就能替换为内存模拟实现。

具体落地步骤：

1. 定义持久层接口：比如创建ZIF_MY_PERSISTENCE，包含业务对象需要的所有持久化方法（load_data()、save_data()等）。
2. 重构业务对象ZIF_MY_BUSINESS_OBJECT，让它依赖ZIF_MY_PERSISTENCE接口：比如load_or_exception()内部调用mo_persistence->load_data()，而非直接写SELECT语句。
3. 实现两个持久层类：
   • 生产环境用ZCL_MY_PERSISTENCE_DB：真实调用数据库OSQL的实现；
   • 测试环境用ZCL_MY_PERSISTENCE_IN_MEMORY：数据存储在ABAP内表中，所有操作都在内存完成，不会持久化。
4. 在集成测试中，将ZCL_MY_PERSISTENCE_IN_MEMORY注入到ZIF_MY_API的业务对象实例中，这样整个测试流程的所有数据操作都在内存中闭环。

这种方案的优势：

• 符合依赖倒置原则，降低业务逻辑和持久层的耦合度，系统扩展性更好；
• 测试逻辑更灵活，你可以完全控制持久层的行为（比如模拟数据库异常、预设复杂数据场景）；
• 单元测试和集成测试可以复用同一个内存持久化实现，维护成本更低。

方案选择建议 #

• 如果是现有系统，不想做大量重构，优先用OSQL Test Double Framework快速实现无持久化集成测试；
• 如果是新系统或者有架构优化计划，优先用注入持久层接口的方式，从根源解决测试持久化的问题，长期收益更高。

内容的提问来源于stack exchange，提问作者user6412004