Das zentrale Element von Unit Tests sind die verwendeten Testklassen. Diese sollten nicht über Parameter verfügen und sind somit in Ihrer Anwendung und Interpretation eindeutig.
Diese Form von Tests sind in Produktivmandanten nicht ausführbar, es besteht also keinerlei Gefahr sich durch die Tests selber zusätzliche Systemlast oder andere Nebenwirkungen einzuhandeln. Auch auf Entwicklerebene bringen Testklassen eine Reihe von individuellen Eigenheiten mit sich.
Eigenschaften von Testklassen
-
-
- Eine in der Klasse definierte Testdauer und Risiko
- Eine Class_Setup Methode, welche einmalig bei Erstellung der Klasse aufgerufen wird.
- Eine Setup Methode, welche vor jeder Testmethode aufgerufen wird.
- Die Testmethoden selbst, welche designed sind mit dem Hintergedanken eine Funktion zu kapseln und gegen ein erwartetes Ergebnis zu vergleichen.
- Eine Teardown Methode, welche am Ende jeder Testmethode aufgerufen wird.
- Eine Class_Teardown Methode, welche einmalig nach der letzten Teardown Methode aufgerufen wird.
-
Praktisch an diesem Framework ist Beispielsweise das automatische Rollback, welches sich im Anschluss an die Ausführung der getesteten Methoden anschließt (Teardown). Es ist weiterhin absolut Empfehlenswert zumindest einmal jeden Testfall zuerst zu einem Fehlerfall geführt zu haben, bevor er korrekt implementiert wird. Dadurch kann verhindert werden, dass die Prüfung des Testfalls selbst einen Fehler enthält. Das ist zwar unwahrscheinlich aber kostet keine Zeit und kann durchaus enorm wichtig werden. Die Chance fehlerhaften Quellcode der mit einem fehlerhaften Testfall überprüft wird wiederzufinden ist Erfahrungsgemäß äußerst gering.
An dieser Stelle direkt eine kleine Warnung. Die getesteten Methoden dürfen sich nicht aufeinander beziehen. Das liegt daran, dass die Ausführung der zu testenden Methoden nicht definiert werden kann.
Wer jetzt noch tiefer in das Detail einsteigen möchte und gerne einmal die Funktionsweise Live und in Farbe sehen möchte, den verweise ich gerne auf den dritten Teil der zugehörigen Blogserie mit dem Thema: “Unit Testing Hands on Beispiel”.
2 Kommentare zu "Unit Testing Testklassen"
Guten Tag,
ich hab mal eine Frage und ich hoffe das ihr mir diese beantworten könnt. Ich frage mich immer noch, was der Unterschied zwischen Unit Testing und Integration Testing ist, gibt es dazu eine Unterscheidung die ihr mir in kurzform anbieten könntet?
Beste Grüße
Guten Tag Herr Neubauer,
Bei einem Unit Test wird gewährleistet, dass ein Element (z.B. eine Funktion) unter optimalen Umständen funktioniert.
Hierbei wird soviel an Abhängigkeiten herausgenommen wie möglich ist.
Datenbankzugriffe werden durch ein Mock-up ersetzt. Fehlerbehandlung / Protokollierung / Logging / Authentifizierung & alle anderen Abhängigkeiten werden durch fehlerfreie Daten ersetzt.
Wenn ein Unit Test ein positives Ergebnis zurückmeldet, kann es also trotzdem sein, dass die Funktion in der Produktiven Umgebung nicht funktioniert Aufgrund von den Abhängigkeiten.
Bei einem Integrationstest wird eine Entwicklung in einer möglichst nah an dem Produktiven Einsatz orientierten Umgebung getestet.
Die Entwicklung, die einen Integrationstest besteht, sollte also auch in der Produktiven Umgebung funktionieren.
Der Knackpunkt ist der folgende.
Wenn nun eine Funktion wie z.B. das Logging fehlerhaft ist und alle anderen Komponenten davon Abhängig sind, sind laut Integrationstest alle Entwicklungen fehlerbehaftet.
Das entspricht zwar der Wahrheit, ist aber nicht sonderlich hilfreich.
Im Gegenzug dazu ist nur genau ein einziger Unit Test fehlerhaft, somit habe ich sofort die Fehlerquelle gefunden.
bei Fragen, fragen.
Beste Grüße,
Lars Ludwig