Unit-Tests
In der Theorie großartig, aber …
Fortsetzung des Artikels von Teil 2
Über den Unit-Test hinausdenken
Wegen dieser einfachen Anwendung kann man Unit-Tests als geeignet für die Entwicklung betrachten, denn jede Prozedur lässt sich testen, sobald sie geschrieben wird. Denn immer, wenn diese Unit-Tests fehlerhaften Code entdecken, kann der Entwickler die nötigen Korrekturen zu einem Zeitpunkt vornehmen, zu dem ihm die ursprüngliche Design-Intention noch präsent ist. Dieser Ansatz nennt sich Test-Driven Development und wird später noch genauer behandelt.
Einige betrachten die Begriffe »Unit-Test« und »Modultest« als gleichbedeutend. Andere wiederum sind der Auffassung, dass der Begriff »Unit« das Testen einer einzelnen Prozedur impliziert, während »Modul«, das innerhalb der Applikation möglicherweise einen bestimmten Zweck zu erfüllen hat, eine Zusammenstellung miteinander zusammenhängender Prozeduren suggeriert. Legt man letztere Definition zugrunde, sind manuell entwickelte Modultests wahrscheinlich einfacher zu konstruieren als Unit-Tests, speziell wenn das Modul einen funktionalen Aspekt der Applikation selbst repräsentiert. In diesem Fall hängen die meisten Prozeduraufrufe miteinander zusammen, und der Code greift auf ebenfalls miteinander zusammenhängende Datenstrukturen zu, sodass sich der Harness-Code unkomplizierter erstellen lässt.Testwerkzeuge machen die Unterscheidung zwischen Unit- und Modultests hinfällig. Denn mit den genau gleichen Prozessen lässt sich eine einzelne Prozedur isoliert prüfen ebenso wie mehrere Prozeduren, eine Datei, mehrere aus Prozeduren bestehende Dateien, eine Klasse (sofern sinnvoll) oder ein Teil der Funktionen eines ganzen Systems. Dies hat dazu geführt, dass die Unterscheidung zwischen Unit- und Modultest inzwischen so irrelevant ist, dass der Begriff Unit-Test mittlerweile beide Konzepte abdeckt.
Jobangebote+ passend zum Thema
Eine solche Flexibilität erleichtert progressive Integrationstests. Haben die Prozeduren die Unit-Tests bestanden, werden sie zu Subsystemen zusammengefügt. Diese wiederum werden anschließend zusammengesetzt, um dann Systemtests durchführen zu können. Ebenso hält diese Flexibilität Optionen bereit, wenn ein pragmatischer Ansatz für weniger kritische Applikationen nötig ist. Ein einziger Satz an Testfällen kann eine spezifizierte Prozedur ebenso ausführen wie alle Prozeduren, die als Resultat der Ausführung der einzelnen Prozedur aufgerufen werden (Bild 2) – oder auch alles dazwischen. Testfälle, die den Funktionsumfang der gesamten Aufrufkette prüfen, lassen sich einfach konstruieren. Auch hier lassen sich die Prozesse abhängig davon kombinieren, wie kritisch der zu prüfende Code ist.
Dieses allumfassende Unit-Test-Konzept lässt sich auch auf Multi-Threaded-Applikationen ausdehnen. In einer Single-Threaded-Anwendung ist der Verarbeitungspfad genau definiert und sequenziell, kein Codeabschnitt wird zeitgleich mit einem anderen ausgeführt. Besteht eine Applikation dagegen aus mehreren Threads, laufen möglicherweise zwei oder mehrere Pfade gleichzeitig ab, und die Kommunikation zwischen den Threads ist ein normales Merkmal des Systems. Unit-Tests können in einem solchen Umfeld gewährleisten, dass sich bestimmte Prozeduren angemessen verhalten – und zwar sowohl intern als auch hinsichtlich ihrer Interaktion mit anderen Threads.
Gelegentlich ist das isolierte Testen einer Prozedur nicht praktikabel. Ist eine Prozedur beispielsweise auf das Vorliegen bestimmter geordneter Daten angewiesen, damit sie ihre Aufgaben ausführen kann, müssen ähnliche Daten bereitgestellt werden, denn nur dann kann ein Unit-Test dieser Prozedur aussagefähige Ergebnisse liefern.
Werkzeuge für Unit-Tests können mehrere verschiedene Prozeduren nicht nur in einem einzelnen Test, sondern auch in einer Abfolge von Tests abdecken, wobei sich jeder Test auf die Rahmenbedingungen des jeweils folgenden auswirkt. So lässt sich eine Prozedur, die auf eine Datenstruktur zugreift, dadurch überprüfen, dass zunächst ein Testfall implementiert wird, der eine Initialisierungsprozedur innerhalb der Applikation aufruft, gefolgt von einem zweiten Testfall, der die eigentlich interessierende Prozedur ausführt.
»Unit-Test« bezeichnet nicht zwangsläufig Testen in einer Entwicklungsumgebung. Die Integration zwischen Testwerkzeugen und Entwicklungsumgebungen bringt es mit sich, dass Unit-Tests von Software nahtlos zwischen Compiler und Zielhardware erfolgen können.
Unit-Tests gleich während der Entwicklung durchzuführen, ist vernünftig. Allzu häufig aber gefährdet Weiterentwicklung den Funktionsumfang einer Software, die eigentlich als vollständig gilt. Derartige Probleme treten besonders dann auf, wird Code, dessen Entwicklung man eigentlich für abgeschlossen hielt, um Funktionen ergänzt.
- In der Theorie großartig, aber …
- Wann und warum sind Unit-Tests gerechtfertigt?
- Über den Unit-Test hinausdenken
- Regressionstests bei erweitertem Code
- Bestehenden Code testen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Einblick in die statische Code-Analyse:
Auf verschlungenen Pfaden
Fünf Ursachen für unliebsame Firmware-Fehler
Rezepte fürs Bugfixing
Anforderungsbasiertes Testen
Richtig verbunden?
Software Engineering
Vom Zufallsprodukt zum planbaren Prozess
Test-Driven-Development
Erst testen, dann codieren
Kodierungsstandards
Warum ein neues MISRA C?
Software unbekannter Herkunft nutzen
Softwareentwicklung in der Medizintechnik: Das Haar in der »SOUP« finden
