Test doubles

Once a dependency can be replaced, something has to replace it. You can write a test double by hand: a small local class that implements the interface and returns fixed data. For many dependencies, though, SAP ships frameworks that create doubles for you, including for things you cannot put behind an interface, such as a database table or a CDS view. Knowing which framework fits which dependency is most of the skill.

Stubs, mocks and fakes

• Stub: returns canned answers. "For customer Great Lakes Fleet Services, the agreement is 45.00 per unit."
• Mock: a stub that also checks how it was called, and fails the test if the expected call did not happen. "The logger must be called once with message type E."
• Fake: a working but simplified implementation, such as an in-memory table instead of the database.

All three are test doubles. Prefer stubs; use mock-style verification only when the interaction itself is the behavior you need to prove. Clean ABAP warns against mocking what the test does not need, because over-specified tests break on harmless refactoring.

Which framework for which dependency

The ABAP OO Test Double Framework

CL_ABAP_TESTDOUBLE creates a double for an interface (or a non-final class) at runtime. You configure it in two statements: first cl_abap_testdouble=>configure_call( double )->returning( value ), then a call on the double that names the method and its input, which tells the framework which call the configuration applies to. You can also raise exceptions, ignore parameters and set expected call counts, then check them with verify_expectations. The framework does not cover local classes or interfaces, classes declared FINAL, FOR TESTING or CREATE PRIVATE, or constructors with mandatory parameters; for those, write the double by hand.

SQL and CDS test doubles

The ABAP SQL Test Double Framework redirects ABAP SQL in the code under test from the real table or CDS entity to a double that the test fills. No design change is needed: Kenji's class can keep its SELECT on ZCMC_CORE_AGR. The CDS Test Double Framework serves a different purpose: it tests the logic inside a CDS view entity (joins, calculations, filters) by replacing the view's own data sources with doubles. SAP's RAP unit testing tutorial uses both, CDS doubles for reads of the BO's view and SQL doubles for the tables it touches.

RAP business objects

When the code under test calls a RAP business object through EML, two framework options exist. The transactional buffer double replaces the BO's transactional buffer, so EML reads and modifications from the CUT work against test instances. The mock EML API lets the test configure what specific EML calls return. Both are created with a list of behavior definition dependencies. The advanced RAP course in this track applies them to draft and event behavior.