Arbeitsweise und Architektur des utPLSQL Unit-Test Framework

Um ein Arbeitsmittel zu nutzen ist es nie verkehrt zu wissen, wie es tickt. Daher werden wir einen kleinen Einblick in die Arbeitsweise und die grundlegende Architektur des utPLSQL Unit-Test Framework geben.

Architektur

Natürlich möchte ich hier nicht auf die internen Architekturentscheidung eingehen, sondern eher die Punkte erläutern, die für uns als Entwickler, die wir unseren Quellcode testen wollen, wichtig sind.
Das utPLSQL Unit-Test Framework muss auf den Umgebungen installiert werden, wo wir den Testcode ausführen wollen. Dies beinhaltet ein paar Packages, Tabellen und Objekttypen, optimalerweise in einem eigenen Schema.
Der Zugriff auf das Framework wird mit entsprechenden öffentlichen oder privaten Synonymen in den anderen Schemata gewährleistet.

Konfiguration

Ein Vorteil in meinen Augen ist, dass wir das Framework nutzen können, ohne uns um die Konfigurationen auf den verschiedene Umgebungen sorgen zu machen. Der Grund dafür sind die Annotationen, die wir nutzen um dem Framework zu sagen, was wir wann haben wollen. Diese hängen am Unit-Test und sind somit überall gleich.

zurück auf Anfang – automatisches Rollback

Bei den Teardown-Prozessen nimmt uns das Framework in gewissen Situationen die Arbeit ab, die Umgebung wieder im ursprünglichen Zustand zu hinterlassen. Mit seinen automatischen Rollback auf eigens erstellte Savepoints sind Änderungen innerhalb des Schemas kein Problem.

Schnittstellen

utPLSQL hilft uns nicht nur bei der Ausführung von Unit-Tests, sondern bringt uns auch Schnittstellen in Form von Vergleichsoperatoren mit, die wir nutzen können um unsere Testlogik aufzubauen. Mit sprechenden Namen wie „be_equal„, „be_between“ und Anderen kann man die Tests wie ein Buch lesen und sie sind auf einen Blick leicht verständlich.

Testausgaben

Uns werden auch einige mächtige Reporting-Tools zur Verfügung gestellt um die Ergebnisse der Tests zu analysieren.
Entweder hübsch aufbereitet als reiner Text, oder in einer erweiterten Aufbereitung für dritte Tools wie zum Beispiel Sonarqube oder JUnit. Natürlich steht dem geneigten Entwickler auch nichts im Wege eigene Reporter zu erstellen und damit das Framework für seine Zwecke zu erweitern. Vergesst dabei nicht zu überlegen ob eure entwickleten Erweiterungen auch für Andere vom Nutzen sein könnte und stellt sie der Community zur Verfügung.

Woher weiß das Framework, was es ausführen muss?

Hierfür nutzt das Framework Annotations, welche genau sagen was wann passieren soll. Diese Annotations befinden sich in der package specification der Tests und sind somit schnell zu identifizieren. Das Framework scannt also den Code in den specs und führt dann wie definiert die Tests aus.

Cache von Annotations

Bei großen Anwendungen mit entsprechend vielen Unit-Tests könnte ein ständiges Scannen der package specifications natürlich zu starken Performanceproblemen führen, da die Anzahl erheblich groß ist. Um dies zu verhindern hat das Framework ein Caching-Mechanismus, der die ermittelten Annotations speichert.
Bei einem Scan werden die Annotations in eine Tabelle abgelegt und ermöglichen somit schneller bei Testausführungen zu sein, denn dann werden nur Inhalte aktualisiert oder hinzugefügt, welche veraltet oder neu sind.

Cache rebuild und purge

Den Aufbau des Caches kann man auch selbst initiieren und somit bei Bedarf aktualisieren, sollte man einmal den Eindruck haben, dass das Framework eine Aktualisierung nicht mitbekommen hat, welches mir persönlich jedoch noch nie passiert ist.
Mit folgenden Aufruf wird der Cache für ein Schema aufgebaut oder aktualisiert.

Es besteht auch die Möglichkeit den bisherigen Cache komplett zu leeren, damit er wieder neu aufgebaut wird. Auch hier wird der betroffene Schemaname angegeben.

Im Anschluss baut man den Cache mit dem rebuild wieder neu auf, oder überlässt dies dem nächsten Testlauf.

Für CI/CD Server, welche immer wieder neu aufgebaut werden, ist dies natürlich ein Alptraum. Dem kann man jedoch entgegenwirken, indem man die Tabellen im Schema des Frameworks, welche den Cache darstellen, sichert und im Prozess vor der Ausführung wieder einspielt.

Wie wir mit den Annotations für unsere Tests arbeiten, erkläre ich im Detail im nächsten Blogeintrag.

Hier geht es zurück zur Blogserie