Aufbau eines Tests – expects

von Daniel Neumann

Im nachfolgenden Blog möchte ich euch den Aufbau eines Tests erklären, was expects sind und wie wir mit ihnen arbeiten.
Wir werden das Ganze gemeinsam an einem kleinen Beispiel einer Rechenfunktion Schritt für Schritt durchspielen.

Der Test

Unsere Testprozeduren beinhalten den Aufruf der zu testenden Programmeinheit und einige Überprüfungen des erzeugten Ergebnisses. Wie umfangreich und detailliert diese Überprüfungen ausfallen sind vom Entwickler oder dem Unternehmen selbst abhängig, wir zeigen hier nur die Möglichkeiten auf, die genutzt werden können anhand eines kleinen Beispieles.

Prüfungen – expects

Kommen wir nun also zum Herzstück unserer Tests – unsere expects. Diese expects führen den Vergleich zwischen dem erhaltenen Wert und dem erwarteten Wert durch und melden das entsprechende Ergebnis. Wir haben auch die Möglichkeit einen optionalen Text zu übergeben, welcher im Fehlerfall angezeigt wird um zum Beispiel einen Hinweis auf die Art des Fehlers zu geben. Dies würde ich immer empfehlen, da man so besser identifizieren kann was schief läuft.

Der Aufbau ist wie folgt:
ut.expect(<Ergebnis> [, ‚Fehlermeldung‘ ] ) . <Vergleicher>( <Erwartung>);
Eine Hand voll Beispiele, welche alle zu einem positiven Ergebnis im Unit-Test führen würden.

Das Ganze geht auch in der negierten Form. indem man ein „not_“ davor stellt.

Wichtig ist zu sagen, dass der Datentyp beim Vergleichen auf beiden Seiten gleich sein muss.
Folgendes

würde mit der Fehlermeldung „Actual (number) cannot be compared to Expected (varchar2) using matcher equal“ quittiert und die Prüfung wird als fehlschlag markiert.

Auflistung der verfügbaren Vergleicher.

  • be_between
  • be_empty
  • be_false
  • be_greater_than
  • be_greater_or_equal
  • be_less_or_equal
  • be_less_than
  • be_like
  • be_not_null
  • be_null
  • be_true
  • equal
  • match

Da die Liste recht lang ist, würde ich euch noch einmal das Cheat Sheet von Jacek Gebal ans Herz legen. Gute Auflistung mit jeweils einem Beispiel. Ausdrucken und bei euch auf den Platz legen! :D

unsere Beispielfunktion – calculate_it

Damit das Ganze etwas anschaulicher wird, wollen wir eine Funktion testen.
Unser Auftraggeber möchte zwei Zahlen und als dritten Parameter die Bestimmung der Rechenoperation übergeben. Wir werden hier zur Veranschaulichung nur die Subtraktion zeigen. Soweit zu unserer Funktion.
Ich möchte hier gleich eine Lanze für Test-driven Development (TDD) brechen und entsprechende Ansatz verfolgen. Erst der Test, dann die Funktion.

Bevor wir den Test schreiben, brauchen wir jedoch eine Hülle für unsere Funktion, damit wir dagegen kompilieren können. Diese Hülle ist leer, da wir ja zuerst den Test und dann die Funktion programmieren.

Und nun noch unsere Hülle für unser Unit-Test.

Damit ist der Grundstein gelegt und wir gucken mal, ob der Test läuft. Natürlich führen wir bei der Entwicklung gezielt unser Testpackage aus, da eine komplette Ausführung aller Tests im Schema nicht notwendig ist.

Jetzt können wir anfangen unsere erste Prüfung einzubauen. Wir lassen die Funktion das Ergebnis in eine Variable geben und diese werden wir mit unserem Framework vergleichen lassen. In unserem Beispiel nutzen wir den Vergleicher to_equal vom Framework. Nicht zu vergessen unseren Text für die Fehlermeldung.

Und die Ausgabe – logischerweise noch fehlerhaft.

Da unsere Funktion ja noch „NULL“ zurück gibt, stimmt der Vergleich natürlich nicht und wir bekommen den Fehler angezeigt.
Jetzt haben wir einen Stand, wo wir jederzeit unseren Test ausführen und damit prüfen können, ob wir mit unserer Entwicklung den richtien Weg gehen. Ich habe hier absichtlich nur eine rudimentäre Prüfung eingebaut, da der Fokus des Blogeintrags auf utPLSQL und nicht TDD liegt.

Machen wir uns also an die Arbeit unsere Funktion zu schreiben, damit der Test „grün“ wird.

Und schauen wir uns die Ausgabe unseres Tests an.

Hmm, das Ergebnis stimmt noch nicht, habe ich wohl die Operanden vertauscht. Dann mal korrigieren.

Und austesten.

Wundervoll, es geht. Wie man sieht, sind die Ausgabe im Gutfall deutlich kleiner. Man möchte ja auch nicht sehen was richtig ist, sonder was schief läuft.

Damit ist unser Beispiel abgeschlossen. Wenn ihr mögt, könnt ihr natürlich die Funktion um weitere Operatoren oder sogar Operanden erweitern. Fehlermeldungen wäre sicher auch nicht schlecht, doch das überlasse ich eurer Kreativität.

Hier geht es zurück zur Blogserie

SCHREIBEN SIE EINEN KOMMENTAR