SAP MDG · ABAP FOUNDATIONS
How can interface-based data providers isolate database access when unit testing custom ABAP logic in SAP MDG?
Move database reads behind an interface and make the business logic call an interface-typed provider. Production uses the database implementation; ABAP Unit supplies a test double returning controlled data. The supplied example demonstrates local and global interface providers and several injection techniques. This is an ABAP design pattern, not an SAP MDG Customizing setting.
Move database reads behind an interface and make the business logic call an interface-typed provider. Production uses the database implementation; ABAP Unit supplies a test double returning controlled data. The supplied example demonstrates local and global interface providers and several injection techniques. This is an ABAP design pattern, not an SAP MDG Customizing setting.
Custom ABAP logic becomes difficult to unit test when it reads live database data directly. Put that read behind an interface so that the calculation or validation depends on a contract rather than a concrete database implementation.
The supplied example defines a local provider contract, implements a filtered flight-data read, and lets the consuming class use a replacement provider during ABAP Unit execution. A second provider implements a global interface for the same purpose. The surrounding example demonstrates constructor, setter, parameter, and back-door injection.
For an SAP MDG implementation, this pattern can separate custom rule logic from its data-access dependency. The flight table and Z-prefixed classes are demonstration objects, not standard MDG configuration or master-data APIs. Start by identifying the read operation to isolate and the fields the business logic actually consumes.
Process flow
- Identify the database-dependent read separately from the calculation or validation to be unit tested.
- Verify the custom table, consumed fields, interface signatures, and supported ABAP syntax in the target development system.
- Define an interface contract for data retrieval and implement the production provider with a filtered SELECT.
- Make the consumer call an interface-typed provider instead of performing the database read directly.
- Choose constructor, setter, parameter, or controlled back-door injection; supply the test double explicitly.
- Implement an in-memory double returning controlled rows and preserve the input contract.
- Define zero-capacity behavior and assert the weighted calculation and parameter forwarding.
- Run ABAP Unit in ADT and debug provider selection, field projection, and initialization side effects.
Referenced tables
| Object | Purpose |
|---|---|
zdemo_abap_fli | Custom demonstration flight table used as the provider return-row type and production read source. The read filters by carrier and projects seat capacity and occupied seats. |
zdemo_abap_tab1 | Separate custom demonstration table modified by the original surrounding class's static constructor; relevant when checking database side effects, not required by the adapted report. |
The remaining configuration, implementation details, and testing guidance continue from this answer more…
Related questions and keywords
Alternative questions
- How do local and global interfaces support test-double injection in ABAP Unit?
- How can I test custom ABAP business logic without reading database tables?
- How do I replace a database provider with a local test double?
Possible questions
- When should I use a local interface instead of a global interface?
- What is the difference between constructor, setter, parameter, and back-door injection?
- Why are some fields initial after INTO CORRESPONDING FIELDS OF TABLE?
- How do I debug which data provider an ABAP Unit test actually uses?
- Does injecting a provider prevent database writes in a class constructor?