OOP ABAP Part 9: Dependency Injection and ABAP Unit

📌 KEY POINTS
✅ Dependency injection (DI): a class receives the objects it needs (DAO, logger, tax calculator) instead of creating them itself.
✅ Constructor injection is the clearest form: dependencies are IMPORTING parameters of the constructor, typed as interfaces.
✅ In ABAP Unit, you inject test doubles — hand-written local classes or generated with CL_ABAP_TESTDOUBLE.
⚠️ A class that does CREATE OBJECT of its own DAO or calls static SELECT helpers cannot be isolated in tests.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 8 created objects in factories. Now the consumer receives them — and tests pass in fakes. (Modularization Part 10 introduced ABAP Unit basics; here we focus on the OO design side.)

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE PROBLEM
METHOD constructor. CREATE OBJECT mo_dao TYPE zcl_order_dao. ENDMETHOD.
The class is hard-wired to the real database access. A test would need specific data in the database, which changes and differs between systems.

━━━━━━━━━━━━━━━━━━━━
▶ 2. CONSTRUCTOR INJECTION
METHODS constructor IMPORTING io_dao TYPE REF TO zif_order_dao.

• Production code (or a factory) passes zcl_order_dao.
• The test passes ltd_order_dao (a test double).
• The class only knows the interface.

━━━━━━━━━━━━━━━━━━━━
▶ 3. OPTIONAL INJECTION WITH A DEFAULT
Existing callers should not change. Make the parameter OPTIONAL; in the constructor: IF io_dao IS BOUND use it, ELSE create the real one. Callers stay compatible; tests inject.

━━━━━━━━━━━━━━━━━━━━
▶ 4. INJECTION VIA FACTORY / INJECTOR
For deep call chains, the factory holds a static attribute for the instance to return. A test-only injector class (FRIENDS of the factory, FOR TESTING) sets a fake into it. This is how SAP recommends isolating dependencies in larger designs.

━━━━━━━━━━━━━━━━━━━━
▶ 5. TEST DOUBLES

• Stub: returns fixed data (order total 1,000).
• Mock/spy: also records calls so the test can verify them (was save called once?).
• Hand-written local class implementing the interface — simple and readable.
• CL_ABAP_TESTDOUBLE: cl_abap_testdouble=>create( 'ZIF_ORDER_DAO' ) generates a double; configure_call( )->returning( … ) then call the method to set the expectation.

━━━━━━━━━━━━━━━━━━━━
▶ 6. ABAP UNIT REMINDERS
FOR TESTING RISK LEVEL HARMLESS DURATION SHORT; setup creates doubles and the class under test (f_cut); one behaviour per test method; cl_abap_unit_assert=>assert_equals.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Run the tests in the code example (Ctrl+Shift+F10).
2. Change the discount threshold in lcl_order_service and watch a test fail.
3. Replace the hand-written stub with CL_ABAP_TESTDOUBLE as in the commented section.

✅ CHECKPOINT: your classes receive their dependencies, and your tests run without depending on database contents.

A discount class created its own DAO internally, so its tests used real sales orders from the development system. After a client copy the orders changed, all tests failed, and the team started ignoring the test results.
They added an optional constructor parameter for the DAO, wrote a small spy double and rewrote the tests to control data completely. Tests became stable across systems, and a later change to the discount threshold was caught by a failing test before transport.

• Creating dependencies inside the class (CREATE OBJECT of concrete DAOs).
• Static helper calls with SELECTs inside business logic.
• Tests relying on database data that changes.
• Typing dependencies as concrete classes instead of interfaces.
• Test doubles that contain business logic themselves.

• Inject dependencies via the constructor, typed as interfaces.
• Use OPTIONAL parameters with defaults to keep callers compatible.
• Keep doubles simple: fixed return values, recorded calls.
• Use CL_ABAP_TESTDOUBLE for global interfaces with many methods.
• Run ABAP Unit in ATC before transport release.

Questions: "What is dependency injection?", "How do you test a class that reads the database?", "Stub vs mock?", "What is CL_ABAP_TESTDOUBLE?"
Strong answer: DI = a class receives its dependencies (typically via constructor, interface-typed) instead of creating them; tests pass stubs (fixed data) or spies/mocks (recorded calls); optional parameters keep callers compatible; factory injectors for deep chains; CL_ABAP_TESTDOUBLE generates doubles for global interfaces with configure_call/returning.