Unit Testing gehört heute zu jeder professionellen Softwareentwicklung – auch in ABAP. Doch gerade in älteren SAP-Releases fehlen oft moderne Mocking-Frameworks(Test Double Framework) oder komfortable Testwerkzeuge. Hier kommen ABAP Test Seams ins Spiel: ein leichtgewichtiges Mittel, um produktiven Code testbar zu machen, ohne ihn zu zerreißen.

Warum Test Seams massiv unterschätzt werden

Test Seams werden in vielen ABAP-Teams unterschätzt, weil ihr größter Nutzen erst in realen Projektsituationen sichtbar wird. Besonders dort, wo komplexe Abhängigkeiten oder Legacy-Code dominieren, zeigen sie ihre wahre Stärke:

Unzuverlässige Testdaten? Kein Problem.
Z.B. im Geschäftspartnerumfeld fehlen oft Adressen, Rollen oder Kommunikationsdaten. Mit Test Seams lassen sich fehlende BP-Daten oder Sonderkonstellationen einfach simulieren – ohne Stammdatenpflege.
Abhängigkeiten zu Funktionsbausteinen gering halten.
Viele klassische BP-Prozesse rufen BAPIs oder Z-Funktionsbausteine auf. Ein Test Seam kann diese Stellen leicht ersetzen – ohne Wrapper-Klassen.
Fehlerfälle präzise nachstellen.
Sehr seltene Fehler (kein BP gefunden, fehlerhafte Rolle, fehlende Berechtigung) lassen sich gezielt erzeugen.
Zeit-/Zufallsabhängigkeiten steuerbar machen.
GUIDs, Timestamps, Randomwerte → per Seam deterministisch im Test.
Legacy-Code wird testbar, ohne große Umbauten.
Ein Seam reicht oft, damit monolithische Altprogramme testbar werden.
Ideal für eingeschränkte Testsysteme und CI-Pipelines.
Es sind weder echte Stammdaten noch echte Tabellenzugriffe nötig.
Perfekt für BP wegen der fragmentierten Tabellenstruktur.
Statt alle Tabellen nachzubauen → nur die relevanten Zugriffe mocken.

Was sind ABAP Test Seams?

Ein Test Seam ist ein Markierungspunkt im Code, der es erlaubt, bestimmte Blöcke im Unit Test gezielt zu überschreiben — ohne den produktiven Code zu verändern.

TEST-SEAM seam_name.
  " produktiver Code
END-TEST-SEAM.

Im Unit Test:

TEST-INJECTION seam_name.
  " Testlogik / Mock-Daten
END-TEST-INJECTION.

Beispiel: SAP Geschäftspartner (BUT000) lesen

Klassendefinition

CLASS zcl_bp_reader DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS get_bp_name
      IMPORTING iv_partner TYPE bu_partner
      RETURNING VALUE(rv_name) TYPE bu_name.
ENDCLASS.

Implementierung mit Test Seam

CLASS zcl_bp_reader IMPLEMENTATION.

  METHOD get_bp_name.

    DATA ls_but000 TYPE but000.

    TEST-SEAM bp_read.
      SELECT SINGLE * FROM but000
        WHERE partner = @iv_partner
        INTO @ls_but000.
    END-TEST-SEAM.

    rv_name = ls_but000-name_first && ' ' && ls_but000-name_last.

  ENDMETHOD.

ENDCLASS.

Ohne Test Seam wäre die direkte DB-Abfrage schwer testbar – mit dem Seam lässt sich diese Stelle im Test ersetzen.

Unit Test: TEST-INJECTION verwenden

Testklassendefinition

CLASS ltc_bp_reader DEFINITION FOR TESTING DURATION SHORT RISK LEVEL HARMLESS.

  PRIVATE SECTION.
    DATA cut TYPE REF TO zcl_bp_reader.

    METHODS:
      setup,
      test_get_bp_name FOR TESTING.

ENDCLASS.

Testimplementierung

CLASS ltc_bp_reader IMPLEMENTATION.

  METHOD setup.
    cut = NEW zcl_bp_reader( ).
  ENDMETHOD.

  METHOD test_get_bp_name.

    " Testdaten simulieren
    TEST-INJECTION bp_read.
      ls_but000-name_first = 'Max';
      ls_but000-name_last  = 'Mustermann';
    END-TEST-INJECTION.

    DATA(lv_name) = cut->get_bp_name( iv_partner = '123456' ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_name
      exp = 'Max Mustermann'
    ).

  ENDMETHOD.

ENDCLASS.

Weitere Test-Seam-Szenarien für SAP Geschäftspartner (BP)

Der BP ist ein komplexes Objekt über viele Tabellen hinweg – ideal für Test Seams. Nachfolgend fünf häufige, praxisnahe Szenarien.

1. Adresse fehlt oder ist ungültig

TEST-SEAM address_read.
  SELECT SINGLE * FROM but020
    WHERE partner = @iv_partner
    INTO @ls_addr.
END-TEST-SEAM.

Testfall: Keine Adresse

TEST-INJECTION address_read.
  CLEAR ls_addr.
END-TEST-INJECTION.

2. BP-Rollen simulieren

TEST-SEAM role_read.
  SELECT * FROM but100
    WHERE partner = @iv_partner
    INTO TABLE @lt_roles.
END-TEST-SEAM.

Keine Rolle:

TEST-INJECTION role_read.
  lt_roles = VALUE #( ).
END-TEST-INJECTION.

Falsche Rolle:

TEST-INJECTION role_read.
  lt_roles = VALUE #( ( role = 'EMPLOYEE' ) ).
END-TEST-INJECTION.

3. Geschäftsbeziehungen (BUT050) simulieren

TEST-SEAM relation_read.
  SELECT * FROM but050
    WHERE partner1 = @iv_partner
    INTO TABLE @lt_rel.
END-TEST-SEAM.

Beziehung vorhanden:

TEST-INJECTION relation_read.
  lt_rel = VALUE #(
    ( partner1 = '10000001' partner2 = '10000002' reltyp = 'BUR001' )
  ).
END-TEST-INJECTION.

Keine Beziehung:

TEST-INJECTION relation_read.
  CLEAR lt_rel.
END-TEST-INJECTION.

4. Bankdaten / Zahlungsinformationen

TEST-SEAM bank_read.
  SELECT * FROM but052
    WHERE partner = @iv_partner
    INTO TABLE @lt_bank.
END-TEST-SEAM.

IBAN vorhanden:

TEST-INJECTION bank_read.
  lt_bank = VALUE #(
    ( bank_acct = 'DE1234567890' bank_ctry = 'DE' bank_key = '50010517' )
  ).
END-TEST-INJECTION.

Keine Bankdaten:

TEST-INJECTION bank_read.
  lt_bank = VALUE #( ).
END-TEST-INJECTION.

5. Kommunikationsdaten (E-Mail / Telefon)

TEST-SEAM comm_read.
  SELECT * FROM adr2
    WHERE addrnumber = @lv_addrnum
    INTO TABLE @lt_comm.
END-TEST-SEAM.

E-Mail vorhanden:

TEST-INJECTION comm_read.
  lt_comm = VALUE #( ( smtp_addr = 'test@example.com' ) ).
END-TEST-INJECTION.

Keine Kommunikationsdaten:

TEST-INJECTION comm_read.
  CLEAR lt_comm.
END-TEST-INJECTION.

Kombination: Mehrere BP-Szenarien in einem Test

" Adresse
TEST-INJECTION address_read.
  ls_addr-country = 'DE'.
  ls_addr-city    = 'Berlin'.
END-TEST-INJECTION.

" Rollen
TEST-INJECTION role_read.
  lt_roles = VALUE #( ( role = 'FLCU01' ) ).
END-TEST-INJECTION.

" Bankdaten
TEST-INJECTION bank_read.
  lt_bank = VALUE #( ( bank_acct = 'DE99...123' ) ).
END-TEST-INJECTION.

Best Practices beim Einsatz von Test Seams

Nur externe Abhängigkeiten mocken: DB-Reads, BAPIs, RFCs, System-Calls.
Sprechende Seam-Namen: bp_read, address_read, authorization_check.
Nicht zu viele Seams setzen – punktuell dort, wo es echten Mehrwert bringt.
Produktive Default-Implementierung beibehalten.
Deterministische Testdaten verwenden.

Vorteile von ABAP Test Seams

Funktionieren sogar in alten Releases (> 7.50)
Minimal-invasiv, kein großer Refactor-Aufwand
Mächtig für Legacy Code
Kein Performance-Overhead
Standard-ABAP – ohne zusätzliche Frameworks

Fazit

ABAP Test Seams sind ein unterschätztes, aber extrem mächtiges Werkzeug, um komplexen SAP-Code testbar zu machen — besonders im Geschäftspartner-Kontext. Sie reduzieren Abhängigkeiten, machen Tests stabil und funktionieren in alten wie neuen Releases. Für Legacy-Systeme und CI-Anforderungen sind sie oft der schnellste Weg zu reproduzierbaren Unit Tests.

ABAP Test Seams: Der unterschätzte Schlüssel zu besseren Tests