Unit-Tests
In der Theorie großartig, aber …
Fortsetzung des Artikels von Teil 4
Bestehenden Code testen
Im Zuge von Unit-Tests ausgegebene Daten sind meist per se schon ein wichtiges Ziel. Dies muss jedoch nicht so sein, zuweilen kann die Tatsache, dass Unit-Tests erfolgreich abgeschlossen wurden, wichtiger sein als die eigentlichen Testdaten. Eine solche Situation liegt vor, wird Quellcode auf Robustheit geprüft. Um dafür gerüstet zu sein, können die Werkzeuge sowohl Testdaten als auch Testfälle automatisch generieren. Allein auf diesem Weg lässt sich eine hohe Codeausführungsabdeckung (Code Execution Coverage) erreichen, und die resultierenden Testfälle lassen sich durch solche ergänzen, die auf dem üblichen Weg manuell erzeugt wurden.
Eine interessante Anwendung für diese Technik hängt mit bestehendem Code zusammen, denn dieser stellt häufig ein wertvolles Gut dar. Er mag sich über viele Jahre in der Praxis bewährt haben, wurde wahrscheinlich aber in einem eher experimentellen Ad-hoc-Verfahren von fachkundigen »Gurus« entwickelt. Diese waren vielleicht Experten darin, Dinge in der Applikation zum Laufen zu bringen, nicht aber im Einhalten moderner Entwicklungsverfahren.
Häufig ist dieser Quellcode unbekannter Herkunft jedoch die Basis für Neuentwicklungen, die modernen Standards gerecht werden müssen – sei es, weil der Kunde dies verlangt oder weil die Entwicklerorganisation das Konzept der fortlaufenden Verbesserung (Continuous Improvement) verfolgt. Zusätzlich verschärfen kann sich die Situation dadurch, dass sich auch die Codierungsstandards selbst fortlau+fend weiterentwickeln, wie die Einführung von MISRA C:2012 [3] deutlich macht.
Ist es jedoch notwendig, den Code neu zu entwickeln, um solche Standards zu erfüllen, reicht es nicht, nur jene Aspekte des Codes zu identifizieren, die diesen Standards nicht genügen. Zusätzlich ist darauf zu achten, dass der Funktionsumfang der Software durch das Einhalten der Standards nicht in unvorhergesehener Weise verändert wird. Der existierende Code kann durchaus die solideste oder auch die einzige verfügbare Dokumentation sein. Deshalb muss gewährleistet sein, dass entsprechend mit ihm umgegangen wird. Automatisch generierte Testfälle lassen sich nutzen, um genau solchen Eventualitäten Rechnung zu tragen. Indem man Testfälle mithilfe des Bestandscodes generiert und sie auf die umgeschriebene Version anwendet, lässt sich nachweisen, dass der Funktionsumfang nur in dem Umfang verändert wurde, wie es von Beginn an angestrebt gewesen war.
Jobangebote+ passend zum Thema
- 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
