Lars Ludwig
30. Oktober 2018

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.

Top 3 Programmierfehler in ABAP für SAP HANA

Whitepaper: Top 3 Programmierfehler in ABAP für SAP HANA

Vermeiden Sie diese Top 3 Fehler bei der Programmierung in ABAP für HANA.

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.

Testklasse generieren

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:

Testklasse mit Methoden

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:

Testmethoden implementiert

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.

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.

Fehlermeldung Test

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.

Lars Ludwig

Lars Ludwig

Guten Tag, mein Name ist Lars Ludwig. Ich bin zertifizierter SAP Berater und bei mindsquare im Fachbereich Custom Solutions tätig. Im Zuge dessen beschäftige ich mich größtenteils mit Usability, User Experience und Sap Oberflächentechnologien.

Sie haben Fragen? Kontaktieren Sie mich!



Das könnte Sie auch interessieren

Ihre Mitarbeiter investieren viel Energie in die Testphasen der Projekte?

weiterlesen

Vermutlich geht es Ihnen wie mir – als SAP ABAP Entwickler ist die SE80 mein zweites Zuhause. Über die Jahre finde ich mich beinahe blind zurecht und habe auch die […]

weiterlesen

SAP IDoc ist ein SAP-Werkzeug, mit denen Sie den Datenaustausch mit Ihren Partnern abbilden können. IDocs werden in SAP für die Übertragung von Informationen bzw. Nachrichten verwendet. Was sich genau […]

weiterlesen

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?

Antworten

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”.

Antworten

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! 😉

Antworten

Schreiben Sie einen Kommentar

Bitte füllen Sie alle mit * gekennzeichneten Felder aus. Ihre E-Mail Adresse wird nicht veröffentlicht.





Kontaktieren Sie uns!
Alexander Koessner-Maier
Alexander Kössner-Maier Kundenservice