Unit-Tests
In der Theorie großartig, aber …
Fortsetzung des Artikels von Teil 3
Regressionstests bei erweitertem Code
Dann sind Regressionstests gefragt. Hat man eine Testfall-Datei, in der die Abfolge der Tests für die ursprüngliche Software unbekannter Herkunft ist (Software of Unknown Pedigree, SOUP, siehe [1]), kann ein Entwickler diese hervorholen und auf den überarbeiteten Code anwenden. So lässt sich nachweisen, dass die ursprünglichen Funktionen nicht beeinträchtigt wurden. Einmal konfiguriert, lassen sich diese Regressionstests als Hintergrundaufgabe initiieren und möglicherweise allabendlich durchführen. Reports können dann etwaige Abweichungen gegenüber dem Output früherer Testläufe markieren. Dadurch lassen sich Codemodi-fikationen, die unbeabsichtigte Änderungen des Applikationsverhaltens zur Folge haben, identifizieren und umgehend berichtigen.Moderne Werkzeuge zum Durchführen von Unit-Tests warten mit grafischen Benutzeroberflächen nach dem Point-and-Click-Prinzip auf, die sich oft einfach und intuitiv bedienen lassen. Hat man es jedoch mit Tausenden von Testfällen zu tun, ist eine GUI nicht immer die effizienteste Option für die Entwicklung von Testfällen. Dieser Erkenntnis folgend sind die Testwerkzeuge so konzipiert, dass die erwähnten Testfall-Dateien direkt aus Applikationen wie etwa Microsoft Excel heraus entwickelt werden können. Wie zuvor kann man dann den Regressionstest-Mechanismus nutzen, um die in diesen Dateien befindlichen Testfälle auszuführen.
Jobangebote+ passend zum Thema
Werkzeuge des Unit-Tests können auch zum Entwickeln von Testfällen für Code dienen, der sich noch in der Konzeptphase befindet. Dieses Verfahren heißt testgetriebene Entwicklung (Test-Driven Development, TDD. Es nutzt kurze Entwicklungs-Iterationen auf Basis zuvor geschriebener Testfälle, die gewünschte Verbesserungen oder neue Funktionen definieren (Bild 3). Jede Iteration erzeugt Code, der die Tests der betreffenden Iteration bestehen muss [2]. Der Programmierer oder das Team passt den Code dann entsprechend den vorgenommenen Änderungen an.
Traditionell wurden viele Applikationen ausschließlich mit funktionalen Mitteln geprüft. Entwickler schrieben den Quellcode entsprechend der Spezifikation und prüften ihn anschließend daraufhin, ob alles korrekt funktionierte. Bei dieser Vorgehensweise gibt es jedoch das Problem, dass unabhängig davon, wie sorgfältig die Testdaten zusammengestellt werden, der Anteil des Codes, der tatsächlich geprüft wird, sehr begrenzt sein kann. Erschwerend kommt hinzu, dass die auf diese Art geprüften Prozeduren wahrscheinlich nur Daten im Bereich der aktuellen Applikation und Testumgebung behandeln. Wenn sich irgendetwas geringfügig ändert – sei es bezüglich der Verwendung der Applikation oder als Resultat geringfügiger Modifikationen am Code – kann es vorkommen, dass die Applikation im Feld in einen völlig ungeprüften Modus hineinläuft. Dies wird nicht passieren, wenn alle Bestandteile des Systems ihre Unit-Tests durchlaufen haben und mit Integrationstests stückweise zusammengefügt wurden. Was aber, wenn Zeit- und Ressourcenknappheit dies nicht zulassen?
Werkzeuge für den Unit-Test bieten häufig an, Code zu instrumentieren. Damit kann man Verarbeitungspfade verfolgen und nachweisen, welche Teile der Applikation während der Verarbeitung angesprochen wurden. Mit diesem Verfahren lässt sich die Codeabdeckung (Code Coverage) ermitteln (siehe Bild 2). Dieser Parameter ist ein wichtiger Aspekt des Prüfprozesses, denn er zeigt, welcher Prozentsatz des Codes während des Tests nicht benutzt und erprobt wurde. Der Nachweis, dass der gesamte Code korrekt benutzt wurde, muss jedoch nicht allein auf Unit-Tests basieren. Vielmehr lassen sich einige Unit-Tests in Kombination mit Systemtests anwenden, um für das System insgesamt die geforderte Ausführungsabdeckung (Execution Coverage) zu erreichen. Dies bedeutet also, dass der Systemtest einer Applikation durch Unit-Tests ergänzt werden kann, um auch solchen Code zu aktivieren, der während der normalen Ausführung der Applikation unbenutzt und damit ungeprüft bliebe. Beispiele für solche Codeabschnitte sind defensiver Code (z.B. um Abstürze bei unerwarteten Divisionen durch Null zu vermeiden) sowie Exception- und Interrupt-Handler.
- 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
