Test-double frameworks

Clean Core code is testable code, and SAP ships three test-double frameworks aimed at three different things — knowing which to reach for is the skill. `cl_abap_testdouble` mocks interfaces: you create a double for an interface, configure what a call returns, and inject it into the class under test, replacing a hand-rolled stub with a configurable one. It is the right tool when your dependency is expressed as an interface, which Clean ABAP encourages precisely so it can be doubled.

`cl_cds_test_environment` isolates CDS test data: it spins up a test environment for a CDS entity, lets you insert controlled rows, runs the view against that data, and tears the environment down afterward — so you can unit-test an analytic or projection view deterministically without depending on whatever happens to be in the real database. RAP test doubles, built around `cl_abap_behv_aux_factory`, let you exercise a behavior pool's logic without committing to the database, mocking the RAP runtime so determinations and validations can be asserted in isolation.

The senior point is to match the framework to the boundary you are isolating: an interface dependency, a CDS read, or RAP behavior. Mixing them up — for example trying to test a CDS view's results by mocking an interface — leads to brittle or meaningless tests. Each framework gives you a fast, repeatable test by replacing exactly one kind of expensive or non-deterministic dependency.

data(lo_env) = cl_cds_test_environment=>create(
  i_for_entity = 'ZI_OPENORDERSBYCUSTOMER' ).
lo_env->insert_test_data( lt_seed_orders ).
select * from zi_openordersbycustomer into table @data(lt_actual).
cl_abap_unit_assert=>assert_equals( exp = 1 act = lines( lt_actual ) ).
lo_env->destroy( ).

Source notes: clean-core-curriculum §9.5