O'Reilly logo

Unit-Tests mit ABAP® Unit by Damir Majer

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

165
8 Ergänzende Techniken zur
Qualitätssicherung
»Es ist das Wesen meiner Kampfkunst, dass du lernst, am Gegner
vor dir auch das kleinste Anzeichen dessen wahrzunehmen, was er
beabsichtigt, dass du es erkennst, solange es noch nicht ausgeführt
ist.«
Miyamoto Musashi
Dieses Kapitel beschäftigt sich mit weiteren Techniken, die Ihre Software noch
qualitativ hochwertiger machen können. Diese Techniken unterstützen den Soft-
wareentwickler dabei, früher Fehlerzustände zu erkennen. Die hier vorgestellten
Techniken sind keine Testtechniken, sondern Methoden der Qualitätssicherung
von Softwareprogrammen.
Übersicht über das Kapitel:
Aktivierbare Checkpoints
ASSERTIONs und BREAK-POINT-Haltepunkte
Checkpoint-Groups und deren Einsatz
Die Techniken, die wir uns jetzt anschauen wollen, gehören zu den Kontrolltech-
niken beim Erstellen von Software. In SAP stehen Ihnen diverse Möglichkeiten
zur Verfügung, Kontrollmechanismen einzusetzen. Diese erlauben es Ihnen, stabi-
lere Software auszuliefern, da Sie an den für Sie wichtigen Programmstellen die
Kontrollmechanismen einsetzen können.
Auf den folgenden Seiten werden wir uns mit Assertions, Breakpoint
s und
Checkpoint-Groups beschäftigen und wie Sie diese in Ihren Programmen einset-
zen können.
8 Ergänzende Techniken zur Qualitätssicherung
166
8.1 Assertions
Assertions bezeichnen Zusicherungen in Programmen. Eine Assertion wird über
die Anweisung
ASSERT als bedingter Checkpoint definiert. Assertions sind entwe-
der immer aktiv oder durch Zuordnung zu einer Checkpoint-Gruppe aktivierbar.
Eine Assertion ist nichts anderes als eine Zusicherung, dass ein bestimmter
Zustand, d.h. ein Inhalt einer Variablen, im Programm auch vorliegt. Die Idee
dieses Konstruktes ist es, dass bestimmte Vorbedingungen (siehe Design by
Contract) eingehalten sind, bevor eine weitere Verarbeitung erfolgen soll.
Die Anweisung
ASSERT werden wir nun in unserer Beispielanwendung einsetzen.
Nehmen wir an, dass die Anforderung explizit vorsieht, dass die Selektionspara-
meter der Reports
ZAU_DISPLAY_FLIGHT_BONUS auf gar keinen Fall leer sein dürfen.
Außerdem sieht die Anforderung vor, dass ggf. der Report durch andere Reports
mit dem ABAP-Befehl
SUBMIT aufgerufen werden soll. Der Auftraggeber wünscht
sich in diesem Fall, diesen Zustand als nie eintreffend zu sehen – entsprechend
robust sollte das Programm erstellt sein.
Diese Anforderung werden wir nicht mit einer Fehlernachricht überprüfen,
sondern mit der
ASSERT-Anweisung, um dadurch zu gewährleisten, dass das Pro-
gramm nicht weiter ausgeführt wird. Die Anweisung
ASSERT bewirkt eigentlich
viel mehr: Ist das Ergebnis der Überprüfung zutreffend, dann wird das Programm
normal fortgesetzt. Wenn das Ergebnis der Überprüfung nicht zutreffend ist,
dann bricht das Programm an dieser Stelle mit dem nicht abfangbaren Laufzeit-
fehler
ASSERTION_FAILED ab.
Gehen Sie in den Report
ZAU_DISPLAY_FLIGHT_BONUS und ändern Sie das Pro-
grammcoding wie folgt ab:
 The Three Amigos: Mr. Good, Mr. Bad and Mr. Pragmatic 
Mr. Bad: Wieso soll ich denn
ASSERT-Anweisungen benutzen? Es gibt doch die Mög-
lichkeit, mit Ausnahmen den Programmfluss zu steuern?
Mr. Good: Die Motivation der Assertions ist es, die Robustheit von Programmen zu
erhöhen, indem sie auf die Korrektheit des Zustands, also beispielsweise eines
Variableninhalts, prüfen. Das Augenmerk ist hierbei darauf gerichtet, dass ein Pro-
gramm so geprüft wird, wie die Anforderungen dies vorgesehen haben.
Mr. Bad: Heißt das etwa, dass die Anforderungen so geprüft werden, wie diese
gestellt worden sind, und dass keine weitere Verarbeitung stattfindet, wenn der
erwartete Zustand (gemäß Anforderung) nicht vorliegt?
Mr. Pragmatic: Ja, genau so ist es. Die Assertions folgen dem Designprinzip
Design by Contract. Und die Anforderungen bzw. deren Spezifizierung über die Vor-
bedingungen werden hier als Vertrag zwischen den Objekten gesehen und beenden
eine Verarbeitung, wenn der Vertrag (also Zustand) nicht eingehalten wird.
167
8.1 Assertions
Listing 8–1
report zau_display_flight_bonus.
...
*------------------------------------------------------*
* B E G I N N D E R V E R A R B E I T U N G
*------------------------------------------------------*
start-of-selection.
assert id ZAU_STARTER CONDITION:
s_car[] is not initial,
s_date[] is not INITIAL,
s_city[] is not INITIAL,
s_citto[] is not INITIAL.
zcl_flight_application=>initialize(
it_carrid = s_car[]
it_fldate = s_date[]
it_cityfrom = s_city[]
it_cityto = s_citto[] ).
Den Report haben wir nun um die ASSERT-Anweisung ergänzt. Wir wollen mit der
Anweisung überprüfen, ob die Selektionstabellen auch wirklich gefüllt sind.
Wenn dieser Zustand nicht eingehalten wird, dann erfolgt an dieser Stelle der
oben genannte Laufzeitfehler.
Die vereinfachte Syntax des
ASSERT-Befehls sieht wie folgt aus:
Das Kürzel
group enthält die Checkpoint-Gruppe und das Kürzel log_exp enthält
den Ausdruck, der auf seinen Zustand hin geprüft wird.
Sichern Sie Ihre Änderungen und prüfen Sie die Syntax. Der Syntax-Prüfer
liefert folgenden Fehler:
Abb. 8–1
Syntaxfehler beim Programm ZAU_DISPLAY_FLIGHT_BONUS
ASSERT [ [ID group ] CONDITION ] log_exp.
© sap AG

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required