This is a test message to test the length of the message box.
Login
ABAP Unit Testbarer Code
Erstellt von Software-Heroes

ABAP Unit - Testbarer Code (Teil 2)

In diesem Artikel geht es um das Thema Test Isolation und wie es unseren Code testbarer macht.

Werbung

Diese Woche fällt der Artikel etwas kürzer aus und wir werden dir nur das Thema Test Isolation näher bringen. Wieso ist es wichtig, seine eigenen Objekte testbar zu programmieren und wie kannst du die Abhängigkeiten zu anderen Objekten reduzieren.

 

Begriff

Bei der Test Isolation geht es vor allem um die Verwendung von Test Doubles um abhängige Komponenten zu steuern. Diese können, ohne Kontrolle, unsere eigenen Tests auf verschiedene Art und Weise beeinflussen:

  • Langsam - Unsere eigenen Tests können durch unbekannte Logik entsprechend langsam werden, da wir die Laufzeit nicht beeinflussen können
  • Defekt - Komponenten können sich in Entwicklung befinden oder durch eine Erweiterung kaputt sein, damit sind automatisch unsere Testfälle ebenfalls fehlerhaft, obwohl unsere Logik noch funktioniert
  • Ausgabe - Durch andere Komponenten kann es zu ungewollten Ausgaben (Anzeige, E-Mail, Erzeugung Belege, etc.) kommen
  • Eingabe - Es kann zu ungewollten Eingaben oder Popups kommen, die unsere Tests pausieren oder zum Absturz bringen

 

Es gibt noch viele weitere Gründe, warum du solche abhängigen Komponenten am besten isolieren solltest. Die Beispiele sollen aber ungefähr aufzeigen, was alles bei der Implementierung der Tests schief gehen kann.

 

Identifizierung

Entsprechend müssen solche abhängigen Komponenten auch identifiziert werden. Diese können zum Beispiel sein:

  • Instanziierung einer anderen Klasse
  • Interaktion mit der Datenbank
  • BAdI erzeugen und verwenden
  • Aufruf eines Funktionsbausteins
  • Ermittlung und Abgleich der aktuellen Uhrzeit

 

Methodik

Wie erreicht man eine Test Isolation? Hierbei gibt es eine ganz einfache Regel, verwende bei jeder Klasse ein Interface und arbeite im aufrufenden Coding genau mit diesem. Verwende bei der Datenhaltung und der Übergabe in Methoden, den Datentyp der implementierenden Klasse, sondern verwende immer nur das Interface. Damit ist am Ende dem aufrufenden Code egal, welches Objekt sich hinter der Referenz verbirgt, solange das Objekt das Interface verwendet.

Hinweis: Die Anlage eines Interfaces für jede Klasse kostet sehr viel Zeit und Disziplin, erzeugt aber ebenso viele neue Objekte im System. Der Aufwand lohnt sich aber und stellt dir für die Zukunft sauber, sowie testbare, Objekte zur Verfügung.

 

Fazit

In diesem Artikel haben wir dir gezeigt, wie den Code separieren kannst und wie dich Interfaces dabei unterstützen, testbaren Code zu schreiben. Im nächsten Artikel werden wir uns das Thema Dependency Injection näher ansehen.


Enthaltene Themen:
ABAP UnitABAPUnit TestsTestbarer CodeTest Isolation
Kommentare (0)

ABAP Unit - Tipps

Kategorie - ABAP

Zum Abschluss der Serie noch ein paar Tipps die wir dir mit auf den Weg geben wollen. Hier geht es um Shortcuts und allgemeine Hinweise zu den Tests.

12.11.2021

ABAP Unit - Software-Architektur

Kategorie - ABAP

Wie könnte die Ziel Architektur in einem SAP System aussehen, wenn wir uns die eigenen Software Komponenten anschauen? Dies wollen wir in diesem Artikel klären.

05.11.2021

ABAP Unit - Testbarer Code (Teil 3)

Kategorie - ABAP

Hier schauen wir uns die Möglichkeiten etwas genauer an, wie man abhängige Komponenten im eigenen Coding zur Testlaufzeit deaktivieren können.

29.10.2021

ABAP Unit - Testbarer Code (Teil 1)

Kategorie - ABAP

In diesem Artikel schauen wir uns an, wie du auch in älterem Code sauber neue Funktionen implementieren und du diese im Anschluss auch testen kannst.

08.10.2021

ABAP Unit - OData testen

Kategorie - ABAP

In diesem Artikel geht es um die Testbarkeit von OData Services und wie du damit auch Schnittstellen einfach und schnell testen kannst.

01.10.2021