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 ABAP unit testing in SAP S/4HANA and writing reliable, maintainable tests for real SAP systems, 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 clean code and refactoring principles I have covered previously—clean architecture and testability go hand in hand.

Using the ABAP Test Double Framework (TDF)

SAP’s built-in Test Double Framework, available since ABAP 7.50, lets you create mock objects for any interface without writing a separate test class. It’s powerful, but it requires you to understand its configuration model.

Step 1: Create the Test Double

CLASS ltc_order_processor_test DEFINITION FINAL FOR TESTING
  DURATION SHORT RISK LEVEL HARMLESS.

  PRIVATE SECTION.
    DATA:
      mo_cut        TYPE REF TO zcl_order_processor,
      mo_repo_mock  TYPE REF TO zif_order_repository.

    METHODS:
      setup,
      test_returns_correct_order_count FOR TESTING,
      test_raises_exception_when_no_orders FOR TESTING.
ENDCLASS.

CLASS ltc_order_processor_test IMPLEMENTATION.

  METHOD setup.
    " Create the test double using TDF
    mo_repo_mock = CAST zif_order_repository(
      cl_abap_testdouble=>create( 'ZIF_ORDER_REPOSITORY' )
    ).

    " Inject it into the class under test
    mo_cut = NEW zcl_order_processor( mo_repo_mock ).
  ENDMETHOD.

Step 2: Configure Stub Behavior

  METHOD test_returns_correct_order_count.
    " Arrange: define what the mock returns
    DATA(lt_fake_orders) = VALUE ztorder_tab(
      ( order_id = '1000000001' customer = '0000001000' status = 'OPEN' )
      ( order_id = '1000000002' customer = '0000001000' status = 'OPEN' )
      ( order_id = '1000000003' customer = '0000001000' status = 'OPEN' )
    ).

    cl_abap_testdouble=>configure_call( mo_repo_mock
      )->returning( lt_fake_orders
      )->when_invoked( ).

    mo_repo_mock->get_open_orders( '0000001000' ).

    " Act
    DATA(lv_count) = mo_cut->process_customer_orders( '0000001000' ).

    " Assert
    cl_abap_unit_assert=>assert_equals(
      act = lv_count
      exp = 3
      msg = 'Expected 3 open orders for customer 1000'
    ).
  ENDMETHOD.

Step 3: Verify Exception Handling

  METHOD test_raises_exception_when_no_orders.
    " Configure mock to raise the exception
    cl_abap_testdouble=>configure_call( mo_repo_mock
      )->raising( NEW zcx_order_not_found( ) 
      )->when_invoked( ).

    mo_repo_mock->get_open_orders( '9999999999' ).

    " Act & Assert
    TRY.
      mo_cut->process_customer_orders( '9999999999' ).
      cl_abap_unit_assert=>fail(
        msg = 'Expected ZCX_ORDER_NOT_FOUND to be raised'
      ).
    CATCH zcx_order_not_found.
      " Test passes — exception was correctly propagated
    ENDTRY.
  ENDMETHOD.

ENDCLASS.

This is clean, readable, and—critically—requires zero database access. The test runs in milliseconds and produces the exact same result on every system, every time.

Building a Fake Repository for Complex Scenarios

Sometimes the TDF's stub configuration becomes verbose when you have many method calls with different parameter combinations. In those cases, I prefer writing a fake implementation—a lightweight in-memory version of the real dependency.

"--- Fake Repository (defined inside the test include) ---
CLASS ltc_fake_order_repository DEFINITION FINAL.
  PUBLIC SECTION.
    INTERFACES zif_order_repository.
    DATA mt_orders TYPE ztorder_tab.  " Test data injected directly
ENDCLASS.

CLASS ltc_fake_order_repository IMPLEMENTATION.
  METHOD zif_order_repository~get_open_orders.
    rt_orders = FILTER #( mt_orders
      USING KEY primary_key
      WHERE customer = iv_customer
        AND status   = 'OPEN' ).
    IF rt_orders IS INITIAL.
      RAISE EXCEPTION TYPE zcx_order_not_found.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

Using the fake in a test becomes extremely readable:

  METHOD test_with_fake_repository.
    " Arrange
    DATA(lo_fake_repo) = NEW ltc_fake_order_repository( ).
    lo_fake_repo->mt_orders = VALUE #(
      ( order_id = '2000000001' customer = '0000002000' status = 'OPEN' )
      ( order_id = '2000000002' customer = '0000002000' status = 'OPEN' )
      ( order_id = '2000000003' customer = '0000002000' status = 'BLOCKED' ) " Should not be counted
    ).

    DATA(lo_cut) = NEW zcl_order_processor( lo_fake_repo ).

    " Act
    DATA(lv_count) = lo_cut->process_customer_orders( '0000002000' ).

    " Assert — only OPEN orders should be counted
    cl_abap_unit_assert=>assert_equals(
      act = lv_count
      exp = 2
      msg = 'Only OPEN orders should be processed'
    ).
  ENDMETHOD.

Fakes are particularly powerful when you need to test multiple method calls, stateful behavior, or complex filtering logic. They are slightly more work to write but dramatically more flexible. The alignment here with good exception handling design is important too—see my detailed series on class-based exception architecture 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 CDS Views performance optimization series—the interface boundary between your CDS consumption layer and business logic layer is also your testability boundary.

If you absolutely must test with real CDS data, use ABAP's test seams (introduced in 7.40) as a last resort—but treat them as a code smell that signals a refactoring opportunity.

Common Mistakes and How to Avoid Them

Mistake 1: Testing the Mock, Not the Logic

A surprisingly common mistake is writing a test where the only thing being verified is that the mock returns what you told it to return. Ask yourself: am I testing the behavior of my class under test, or just the wiring of my test setup?

Mistake 2: Over-specification

Configuring your mock to verify that a method was called with exactly these parameters in exactly this order makes your tests fragile. Mock behavior, not implementation details. If the internal call sequence of a method isn't part of its public contract, don't assert on it.

Mistake 3: Sharing Mutable State Between Tests

Always create fresh test doubles in the SETUP method. If one test modifies the state of a fake repository and the next test inherits that state, you get mysterious, order-dependent failures. This is one of the hardest bugs to diagnose in test suites.

Mistake 4: Ignoring the Refactoring Cost

Retrofitting dependency injection into tightly coupled legacy code is hard. Be honest about the cost. I’ve seen teams spend more time fighting legacy code structure than writing actual tests. Prioritize testability in new code; tackle legacy code incrementally with the techniques in my clean code refactoring guide.

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.