Klassisch gesehen ist das Unit-Testing in der IT ein Thema, welches in der Softwareentwicklung beheimatet ist. Aber zum einfacheren Verständnis auch vergleichbar mit dem Vorgehen aus der Praxis allgemeiner Fertigungsprozesse.
Betrachtet man bspw. die Fertigung eines Autos, so wird hier nicht lediglich eine Teileliste erstellt, alles zusammengebaut und nach Vollendung geprüft, ob es nun wirklich ein funktionsfähiges Auto geworden ist. Bei der Fertigung eines Autos ist es wahrscheinlich für jeden relativ plastisch und klar, dass es viele Bauteile gibt, deren Funktionen einzeln getestet werden können und werden. Die benötigten Eigenschaften und Parameter eines jeden Teils werden definiert und können somit überprüft werden, weit bevor sie ihren Weg in ein Fahrzeug finden.
Die Softwareentwicklung kann hier ganz ähnlich betrachtet werden. Es gibt eine Software, die zu erstellen ist und bestimmte Eigenschaften zu erfüllen hat. Die finalen Eigenschaften werden im Allgemeinen heruntergebrochen, der Gesamtkomplex der Software wird auf viele kleine „Bauteile“ oder Units aufgeteilt. Jede dieser Units kann über bestimmte Eigenschaften beschrieben werden, d.h. jede Unit hat eine gewisse Signatur, bestehend aus Parametern, die von außen hineingehen, und Ergebnissen, die am Ende wieder herauskommen.
Was ist das Ziel beim Unit-Testing?
Ansatz und Ziel beim Unit-Testing ist es, direkt bei der Implementierung der einzelnen Units die Expertise aus Design und Entwicklung zu nutzen und Testfälle daraus abzuleiten. Die Idee dahinter ist, dass die Beteiligten aus dem Design genau wissen, welche Anforderungen die einzelne Unit zu erfüllen hat. Sie betrachten die Unit jedoch als eine Art Blackbox. Der Entwickler hingegen kennt den Code und kann somit den Test ggf. noch ein wenig ausfeilen, da er jede einzelne Verzweigung, die sich in der Implementierung ergibt, genau kennt.
Das Ziel der definierten Testfälle ist, dass möglichst sämtliche „Wege durch den Code“ durch einen Testfall abgedeckt sind. Eine 100%ige Abdeckung ist nicht immer zu erreichen, da dies mitunter auch davon abhängig ist, wie feingranular die einzelnen zu testenden Units gefasst werden.
Nicht selten kann es beim Unit-Testing vorkommen, dass – je nach verwendetem Framework – das Schreiben der Tests schnell die Zeit und den Aufwand erreicht, wie es das Schreiben des eigentlichen Codes benötigt.
Wie werden Unit-Tests umgesetzt?
Unit-Tests werden sinnvollerweise von den Entwicklern parallel mitentwickelt, wobei die (groben) Testfälle zum Teil ggf. bereits im Design definiert werden können. Die Tests können auf unterschiedlichster Granularitätsstufe umgesetzt werden. Je tiefer man in den Code hineingeht, umso höher ist die Abdeckung, die realistisch mit den Testfällen erreicht werden kann. Je größer die Flughöhe gewählt wird, desto schwieriger ist es, sämtliche Varianten abzudecken. Bei späteren Detailänderungen ist es dann ggf. schwerer zu erkennen, ob die neuen Gegebenheiten bereits durch die Tests abgedeckt sind oder nicht.
Für die klassische Softwareentwicklung gibt es entsprechende Frameworks, die es ermöglichen, dass der Code bereits parallel zur Implementierung schnell und einfach die zugehörigen Tests durchlaufen kann. Spätestens aber beim Einchecken der Artefakte in ein Repository oder in nächtlichen automatisierten Läufen, wo der Code anhand der Tests überprüft wird und entsprechende Protokolle generiert werden.
Wie Unit-Testing in PowerCenter angewandt werden kann, erfahrt ihr im PDF!
