Unit-Tests
In der Theorie großartig, aber …
Fortsetzung des Artikels von Teil 1
Wann und warum sind Unit-Tests gerechtfertigt?
Unit-Tests sind nicht immer zu rechtfertigen und gelegentlich ist es weiterhin möglich, Unit-Tests vorzunehmen, ohne ein entsprechendes Werkzeug hinzuzuziehen. Gefragt ist eine pragmatische Einschätzung, die man anhand folgender Fragen recht einfach treffen kann:
- Welche Folgewirkungen hätte es, wenn die Software versagt? Wären Todesopfer zu beklagen, etwa bei der Flugsteuerung eines Luftfahrzeugs?
- Drohen überproportional große wirtschaftliche Schäden, etwa bei einer kontinuierlich arbeitenden Produktionsanlage für Kunststoffe?
- Sind extrem hohe Rückrufkosten zu erwarten, z. B. bei Korrekturen an der Steuerung eines Automotors?
Lautet die Antwort in einem dieser Fälle Ja, sind gründliche Unit-Tests unerlässlich, und jedes Werkzeug, das hier Hilfestellung leisten kann, ist sinnvoll. Wenn eine Software aber ausschließlich für interne Zwecke entwickelt wird oder es sich um einen Prototyp handelt, wäre der Aufwand für Unit-Tests zu groß – von den allerwichtigsten Prozeduren einmal abgesehen.Wie nicht anders zu erwarten, gibt es zwischen diesen beiden Bereichen eine Grauzone. Angenommen, die zu entwickelnde Anwendungssoftware steuert eine mechanische Messvorrichtung, die in nur geringen Stückzahlen in einer überschaubaren Region verkauft wird. Wären gelegentliche Ausfälle hier eher hinzunehmen als der Aufwand für Unit-Tests? In einem solchen Fall kann es sinnvoll sein, die Testaktivitäten auf jene Abschnitte der Software zu beschränken, die entweder kritisch oder komplex sind. Wenn ein Softwarefehler dazu führt, dass das Display in einer seltsamen Farbe leuchtet oder ein gelegentlicher Reboot erforderlich ist, mag dies unangenehm sein, aber Unit-Tests noch nicht rechtfertigen. Anders ist es bei Codeabschnitten, die Reports darüber generieren, ob gefertigte Teile maßhaltig sind: Hier können Unit-Tests unerlässlich sein.
Jobangebote+ passend zum Thema
Wann also sind Werkzeuge für den Unit-Test gerechtfertigt? Wieder einmal sind die Kosten maßgebend: Je später während der Produktentwicklung ein Defekt aufgedeckt wird, umso teurer gestaltet sich dessen Behebung (Bild 1). Diese Annahme, die Frederick P. Brooks 1975 in dem Werk The Mythical Man Month aufstellte, hat sich seither in verschiedenen Studien immer wieder bestätigt.
Die Automatisierung jeglichen Prozesses verändert dessen kommerzielle Rechtfertigung. Dies gilt ganz speziell für Testwerkzeuge, da sich dadurch Unit-Tests schon in einem frühen Entwicklungsstadium leichter umsetzen lassen. Deshalb setzen moderne Unit-Tests solche Tools beinahe schon voraus, sobald auch nur eine Handvoll Prozeduren im Spiel sind. Die wichtigste Aufgabe solcher Werkzeuge besteht darin, den Harness-Code, der die wichtigen und nachgeordneten Aufruffunktionen und Prozeduren bereitstellt, automatisch zu generieren. Diese Tools erleichtern das Kompilieren und können einen Unit-Test auch durchführen.
Neben dem Erstellen dieses Harness-Codes nehmen die Werkzeuge auch eine statische Analyse des Quellcodes vor, um die Einzelheiten eines jeden Eingangs- und Ausgangsparameters sowie jeder globalen Variable in leicht verständlicher Form auszugeben. Wenn Unit-Tests an einem isolierten Codeabschnitt ausgeführt werden, ist die Bereitstellung von Stubs für die aufgerufenen Prozeduren auch ein wichtiger Aspekt. Dies lässt sich ebenfalls automatisieren, um die Effizienz des gesamten Verfahrens zu steigern.
Mit dieser Automatisierung lassen sich die Werte zu der getesteten Prozedur recht einfach zuweisen. Denn die Person, die das Testwerkzeug bedient, muss nur wenig über den zu testenden Code wissen. Daraus resultiert – wie zuvor beschrieben – auch die geforderte Objektivität beim Unit-Test: Der Prüfprozess wird von der Code-Entwicklung losgelöst, wo immer die Umstände dies erfordern. Ganz pragmatisch gesehen verringert sich hierdurch auch das zum Entwickeln von Unit-Tests erforderliche Fähigkeitsniveau erheblich.
- 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
