die Welt der Annotations in utPLSQL
Nun tauchen wir ab in die mächtige Welt der Annotations und wie diese im utPLSQL-Unit-Test-Framework genutzt werden.
Wie im vorherigen Blogpost schon erwähnt, kommt das Framework ohne komplizierte Konfigurationseinstellung daher. Der Grund dafür liegt in der Verwendung von Annotations, wie sie in modernen, objektorientierten Programmiersprachen benutzt werden.
Allgemeines
Die Annotations werden in der package specification eingetragen und liegen so, zusammen mit den Unit-Tests, an einem Punkt und machen Konfigurationsdateien oder -tabellen unnötig.
Wenn wir unseren Test starten, geht das Framework durch alle package specifications durch und sucht nach diesen Annotations. Mit den ausgelesenen Informationen werden dann die Test automatisch konfiguriert, in die entsprechenden Suites gekapselt, ausgeführt und das Ergebnis erzeugt. Man hat also die gesamte Kontrolle mit seinen Tests zusammen an einem Punkt.
Aus dem Gesichtspunkt der Struktur her gibt es zwei unterschiedliche Punkte, wo wir Annotations verwenden. Zum Einen am Anfang der package specification, wo Konfigurationen für das gesamte Package gebündelt stehen und zum Anderen vor jeder Prozedur um ihren Platz und Zweck innerhalb der Unit-Tests zu definieren.
- am Anfang der package specification ( z.B. %suite , %suitepath , %rollback )
- vor der Prozedur ( z.B. %test , %beforeall , %beforeeach )
Die Namen der Annotations sind recht sprechend, sodass man daran auch leicht erkennen kann, was oder wann etwas Entsprechendes passiert.
die automatische Rollback-Funktion
Standardmäßig ist eine automatische Rollback-Funktion bei der Durchführung der Tests aktiv. In diesem Modus werden bestimmte Savepoints vor der Testdurchführung erstellt, auf die am Ende wieder zurückgesetzt wird.
Wenn der Code, den man mit dieses Tests testet keine Transaktionssteuerbefehle ( commit, rollback, oder implizit durch DDL ) beinhaltet, wird hiermit automatisch auf den Punkt vor der Testdurchführung zurückgerollt. Somit hinterlassen die Tests nichts, was eine weitere Ausführung behindern könnte.
Sollten Aufgrund der fachlichen Anforderungen Transaktionssteuerbefehle vorhanden sein, muss man seine Tests per Annotation auf manuellen Rollback stellen ( %rollback(manual) ) und selbst dafür sorgen, dass alles wieder aufgeräumt wird. Wenn dies nicht getan wird, quittiert der Unit Test dies mit einer entsprechenden ORA-Meldung und beendet sein Dienst.
Ausnahmen sind hier Prozeduren, welche in einer autonomen Transaktionssteuerung laufen. Hier muss jedoch aufgepasst werden, dass entsprechende Inhalte im Test wieder aufgeräumt werden, damit die Tests jederzeit wiederholbar sind.
Beispielablauf
Hier ein kleines Beispiel einer Test package specification, an der ich kurz den Ablauf skizzieren möchte.
Wenn wir unser Test-package aufbauen, erstellen wir für verschiedene Zwecke eigene Prozeduren, wo wir mit hilfe der Annotations dem Framework mitteilen können, wann und warum diese Prozedur ausgeführt wird.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
create or replace package test_beispiel as -- %suite(Aufzeigen der Grundstruktur) -- %suitepath(blogbeispiele) -- %beforeall procedure startup; -- %afterall procedure teardown; -- %beforeeach procedure test_setup; -- %aftereach procedure test_cleanup; -- %test(Beinhaltet ein paar Tests) procedure test_eins; -- %test(Beinhaltet ein paar Tests) procedure test_zwei; end test_beispiel; |
In unserem Beispiel haben wir 6 Prozeduren. Die Prozedur startup ist mit der Annotation %beforeall markiert, und läuft somit vor allem anderen. Ähnlich sieht es mit der Prozedur teardown und der Annotation %afterall aus, und wird am Ende des kompletten Prozesses ausgeführt.
Die Annotation %beforeeach bewirkt, dass die Prozedur test_setup vor jedem einzelnen Test läuft, wohingegen die Annotation %aftereach der Prozedur test_cleanup bewirkt, dass diese nach jedem Test läuft.
Jede Prozedur, die mit der Annotation %test markiert ist, wird als Test angesehen und entsprechend der Reihe nach ausgeführt.
Der Ablauf für das obige Beispiel wäre also wie folgt:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
erstellt den savepoint "beforeall" execute startup erstellt savepoint "beforeeach" execute test_setup execute test_eins execute test_cleanup rollback auf savepoint "beforeeach" erstellt savepoint "beforeeach" execute test_setup execute test_zwei execute test_cleanup rollback auf savepoint "beforeeach" execute teardown rollback auf savepoint "beforeall" |
Natürlich muss man nicht alle hier beschriebenen Prozeduren in seinem Test aufnehmen. Wenn man zum Beispiel keinerlei Aufräumaktionen benötigt, da alles mit dem automatischen Rollback wieder entfernt wird, muss auch kein %afterall oder %aftereach deklariert werden. Man nimmt also nur das, was man auch wirklich braucht. Das erleichtert den Überblick und erhöht die Wartbarkeit.
SCHREIBEN SIE EINEN KOMMENTAR