ABAP Unit - Testbarer Code (Teil 2)

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.