If yoy have been writing ABAP unit tests for a while, you have probably hit the same wall I did years ago: your tests pass in isolation but become brittle the moment they touch a database table, a remote function call, or a business object manager. The root cause is almost always the same—uncontrolled dependencies. Learning how to isolate those dependencies using ABAP test doubles and mocking frameworks is one of the most impactful skills a senior SAP developer can develop. This guide walks you through that skill in depth, with real-world patterns you can apply immediately.
Before we dive in, if you haven't read my earlier articles on , I’d recommend starting there. This article builds on those foundations and takes you to the next level: true dependency isolation.
Why Dependency Isolation Matters More Than You Think
Let me paint a picture you will recognize. You write a clean ABAP class—ZCL_ORDER_PROCESSOR—and it works perfectly. You even write a unit test. But your test calls the real BAPI_SALESORDER_CREATEFROMDAT2, which creates actual sales orders in your development client. Your test suite runs for 40 seconds. A colleague runs it on a different system and it fails because the customer number doesn't exist there.
That's not a unit test. That's an integration test wearing a unit test costume.
True unit tests must be:
Fast — Milliseconds, not seconds
Isolated — No database, no RFC, no file system
Deterministic — Same result every time, on every system
Self-contained — No setup data required outside the test class
Achieving this requires controlling your dependencies—and that means test doubles.
The Four Types of Test Doubles You Need to Know
The terminology here comes from Gerard Meszaros; classic work on xUnit patterns, and it maps cleanly to ABAP:
1. Dummy Objects
Passed around but never actually used. Often used to fill parameter lists when the value doesn’t matter for the test case at hand.
2. Stubs
Return canned answers to calls made during the test. They don't verify anything—they just provide predefined responses. Use these when your class under test reads data from a dependency.
3. Mocks
Pre-programmed with expectations about which calls they should receive. They verify behavior—meaning they fail your test if an expected method was not called or was called with wrong parameters.
4. Fakes
Working implementations that take shortcuts—an in-memory repository instead of a real database, for example. These are the most sophisticated and most useful in complex ABAP scenarios.
In practice, the ABAP Test Double Framework blurs these categories a bit, but understanding the conceptual distinction shapes how you design your tests.
Setting Up Your Architecture for Testability
You can't retrofit test doubles onto poorly structured code. The single most important prerequisite is dependency injection. If your class instantiates its own dependencies internally, you have no way to replace them in tests.
Here’s the pattern I use in every project:
"--- Interface Definition ---
INTERFACE zif_order_repository.
METHODS:
get_open_orders
IMPORTING iv_customer TYPE kunnr
RETURNING VALUE(rt_orders) TYPE ztorder_tab
RAISING zcx_order_not_found.
ENDINTERFACE.
"--- Production Implementation ---
CLASS zcl_order_repository DEFINITION PUBLIC CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES zif_order_repository.
ENDCLASS.
CLASS zcl_order_repository IMPLEMENTATION.
METHOD zif_order_repository~get_open_orders.
SELECT * FROM ztorders
WHERE customer = @iv_customer
AND status = 'OPEN'
INTO TABLE @rt_orders.
IF rt_orders IS INITIAL.
RAISE EXCEPTION TYPE zcx_order_not_found.
ENDIF.
ENDMETHOD.
ENDCLASS.
"--- Consumer Class (Dependency Injected) ---
CLASS zcl_order_processor DEFINITION PUBLIC CREATE PUBLIC.
PUBLIC SECTION.
METHODS:
constructor
IMPORTING io_repository TYPE REF TO zif_order_repository,
process_customer_orders
IMPORTING iv_customer TYPE kunnr
RETURNING VALUE(rv_count) TYPE i
RAISING zcx_order_not_found.
PRIVATE SECTION.
DATA mo_repository TYPE REF TO zif_order_repository.
ENDCLASS.
CLASS zcl_order_processor IMPLEMENTATION.
METHOD constructor.
mo_repository = io_repository.
ENDMETHOD.
METHOD process_customer_orders.
DATA(lt_orders) = mo_repository->get_open_orders( iv_customer ).
rv_count = lines( lt_orders ).
" ... additional processing logic ...
ENDMETHOD.
ENDCLASS.
Notice that ZCL_ORDER_PROCESSOR depends on the interface ZIF_ORDER_REPOSITORY, not the concrete class. This is the foundation that makes every test double strategy possible. This principle aligns directly with the to understand how to propagate errors cleanly from your fakes.
Handling CDS Views and Database Access in Tests
One of the trickiest scenarios in modern SAP development is testing code that reads from CDS views. If your class calls a CDS view directly via inline SELECT, you can't easily mock it without architectural changes.
The solution is to wrap CDS access in a repository interface—exactly the pattern shown above. Your production repository queries the CDS view; your test uses a fake or mock. This approach integrates naturally with the layered CDS architecture I’ve described in the .
Structuring Your Test Classes for Maintainability
As your test suite grows, organization becomes critical. Here is the structure I recommend:
One test class per behavior scenario — Don't cram all tests into a single LTC_ class. Use separate local test classes for distinct behaviors (happy path, error cases, edge cases).
Descriptive method names — test_returns_zero_when_customer_has_no_open_orders is far more useful than test_01 when diagnosing failures at 2am.
Arrange-Act-Assert structure — Every test method should follow this pattern. It makes tests readable at a glance and forces you to think clearly about what you’re actually testing.
Short test methods — If a test method exceeds 20-25 lines, it's probably testing too many things. Split it.
Key Takeaways
After years of building and reviewing ABAP systems, here is what I can tell you with confidence:
Test doubles are not a testing luxury—they’re a design quality indicator. If you can't mock a dependency, your architecture has a coupling problem.
The ABAP Test Double Framework is production-ready and sufficient for most scenarios. Learn it deeply before reaching for more complex solutions.
Fake implementations are your best friend when testing complex stateful interactions. Don’t be afraid to write them—they’re part of your test suite, not production code overhead.
Dependency injection via constructor is the single most important pattern for ABAP testability. Apply it consistently in all new code.
Clean test code is just as important as clean production code. Treat your test classes with the same architectural discipline you apply to your business classes.
What's Next?
In the next article in this testing series, I will tackle one of the most requested topics from my readers: testing RAP business objects and ABAP RESTful application handlers—where the frameworks built-in test infrastructure opens up some genuinely exciting possibilities. Stay tuned.
In the meantime, pick one class in your current project that has no tests. Identify its external dependencies. Draw the interface boundaries. Then write your first test double. That first step is almost always the hardest—and the most rewarding.
Have questions about a specific mocking scenario you are struggling with? Drop a comment below—I read every one and do my best to respond with concrete advice.
SOCIAL SHARE CARD GENERATOR