Unit Testing Hands on [Beispiel]
Nachdem wir bereits in dem vorherigen Beitrag der Serie: Unit Testing Testklassen festgestellt haben, wie genau eine Testklasse aussieht, demonstriere ich das ganze anhand eines simplen Beispiels nun im Einsatz.
Die Fachliche Anforderung
Die Fachliche Anforderung muss bis im Detail klar definiert sein. Für unser Beispiel stellen wir uns folgende Aufgabe vor:
Für ein neues System sollen neue User IDs vergeben werden. Diese neuen IDs sollen aus 2-10 Zeichen bestehen. Buchstaben gefolgt von 2 Zahlen.
Die Anzahl an Zeichen insgesamt soll über einen Eingabeparameter geschehen und falls dieser außerhalb des Scope liegt, also unter zweistellig oder über 10-stellig, dann wird ein Fehler geworfen.
Wenn wir das Ganze nun im Test Driven Development Modus betrachten wollen, müssen wir uns an dieser Stelle erst darüber klar werden, mit welchen Tests wir nachher belegen wollen, dass unser Produkt den fachlichen Anforderungen genügt.
Erstellen einer passenden Testklasse
Das Erstellen einer Testklasse können Sie per Hand als lokale Klasse in Angriff nehmen oder sich automatisch mit ein paar Klicks generieren lassen.
In der SE80 Rechtsklick auf die Klasse, “Anlegen -> Testklasse generieren” funktioniert ebenfalls.
In beiden Fällen sollte ein immer gleiches Grundgerüst herauskommen. Eine lokale Klasse mit Duration und Risk Level.
Hier pflegen wir nur für unseren Test notwendige, einzelne Prüfungen ein. Jeweils als einzelne Methode mit der Endung: “For Testing”.
Weiterhin sollte sich auch immer eine Referenz auf die zu testende Klasse wiederfinden, damit wir nachher die Methoden der zu prüfenden Klasse verwenden können.
Das kann in unserem Beispiel dann so aussehen:
Implementierung der Testfälle
Nachdem wir also den Rumpf haben setzen wir uns jetzt daran, die Testmethoden zu formulieren. Hier ist die Klasse cl_abap_unit_assert die Trumpfkarte. Diese verfügt über diverse Methoden um Vergleiche auszuführen. Der einfachste Vergleich ist, ob ein gelieferter Wert dem erwarteten Wert entspricht.
In unserem Beispiel fokussieren wir uns zunächst auf folgende Testfälle:
Der erste Test ist bereits Trickreich. Ich erwarte hier einen Fehler vom Typ ZCX_ID_ERROR. Wenn dieser ausbleibt weise ich die oben genannte Klasse an, den Test als fehlerhaft abzuschließen. Wenn ich stattdessen in den Catch laufe, dann habe ich den Test fehlerfrei abgeschlossen.
Der zweite Testfall ist ein simpler Vergleich. Fordere ich eine 10 Stellige ID an, bekomme ich auch eine 10 Stellige ID zurück?
Der dritte Testfall ist in seiner Prüfung wieder etwas komplexer. Hier schaue ich, ob ich in meiner Antwort wirklich auch 2 Zahlen erhalte.
Testen Anhand der Testfälle
Diese Testfälle können also wie bereits zuvor erwähnt erstellt werden, bevor der fachliche Quellcode steht. Beim Bauen der Lösung können wir mit der Tastenkombination: STRG-SHIFT-F10 prüfen, ob unsere Testfälle erfolgreich durchlaufen werden. Zunächst werfen wir dazu einen Blick auf die fachliche Logik.
Ich habe mir den Spaß erlaubt, das Werfen des Fehlers auszukommentieren. Die Erwartungshaltung ist also, dass ich beim Prüfen auf einen Fehler laufe.
Genau das passiert auch.
Ich sehe also, dass eine Funktionalität fehlt / fehlerhaft funktioniert. Offensichtlich ist hier der auskommentierte Quellcode fehlend. Ich spare mir an dieser Stelle das Einkommentieren und Frage stattdessen Sie: Verlassen Sie sich lieber darauf, dass sich schon jemand melden wird, wenn eine Änderung im Coding zu Fehlern in einer andere Anwendung führt oder vertrauen sie lieber auf automatische Tests? Denn diese Testfälle lassen sich in der Testworkbench wenn gewünscht auch z.B. täglich durchlaufen.
Save as PDF
3 Kommentare zu "Unit Testing Hands on [Beispiel]"
Oh man, Tests mit ABAP habe ich mir ja schon schlimm vorgestellt, aber sooo schlimm? 😉 Da kann ich mir schon denken, dass die Akzeptanz bei den Entwicklern gegen Null geht. Oder was ist deine Erfahrung? Setzt das wirklich jemand in der Praxis ein?
Hallo Stefan! Na klar wird das in der Praxis eingesetzt. Es wird nach wie vor in ERP-Systemen viel in ABAP programmiert und nahezu jedes Unternehmen hat umfangreiche selbstentwicklete Applikatinen auf Basis des SAP Standards im Einsatz.
Gerade im Zusammenspiel SAP Standard / eigene Entwicklungen sind automatisierte Tests viel im Einsatz. Das Solution Manager Testmanagement entwickelt in Kombination mit ABAP Unit auch erst so richtig Bums.
Ich erfahre Akzeptanzprobleme eher nicht bei den Entwicklern, als vielmehr bei den Projektverantwortlichen. Da ist dann die übliche Überzeugungsarbeit nötig: “Mehr Aufwand bei der Erstellung automatisierter Tests kostet zuerst und spart später”.
Das finde ich gut! Mir persönlich wäre auch ein noch so gruseliges Testframework lieber als gar keins! Für unsere Haussprache Natural (sehr ähnlich zu ABAP) habe ich daher einfach selbst eins entwickelt. Aber ich kenne Entwickler, die trotz eines ausgereiften und einfach einzusetzenden Frameworks wie JUnit keine Tests schreiben, weil sie den Vorteil nicht sehen (oder nicht verstehen, wie sie anfangen können).
Die Diskussion mit den Projektleitern kann ich mir lebhaft vorstellen. SAP-Projekte sind ja ohnehin nicht für ihre geringen Kosten bekannt und jetzt auch noch automatische Tests!? Braucht doch keiner! 😉