Unit-Tests In der Theorie großartig, aber …

In nicht sicherheitskritischen Bereichen herrscht die Meinung vor, Unit-Tests, wie sie in der Medizin- und Bahntechnik sowie der Luftfahrt Pflicht sind, seien eine nette Idee, in ihrem eigenen Bereich aber wirtschaftlich nicht zu rechtfertigen. Ist eine solche Ansicht noch uneingeschränkt gültig?

von Jared Fry, Field Application Engineer bei LDRA.

Unit-Tests gibt es schon fast so lange wie die Software-Entwicklung selbst. Schließlich ist es auch sinnvoll, zunächst jeden Baustein einer Applikation einzeln zu erstellen und mit Testdaten auszuführen. So kann man sich vergewissern, dass die jeweilige Programmeinheit auch das tut, was sie soll, ohne dass Eingangsinformationen vom Rest der Applikation Verwirrung stiften können.

In der Vergangenheit erwies sich die fehlende Möglichkeit, eine Softwarekomponente einfach aus ihrer Entwicklungsumgebung herauszulösen, zu kompilieren und auszuführen, als problematisch – von der Versorgung mit Testdaten ganz zu schweigen. Um dies zu ermöglichen, ist ein Harness Code nötig. Dies ist ein Programm, das die Programmeinheit aufruft, eventuell benötigte Dateien vorhält (diese Stubs fangen von der Unit ausgehende Prozeduraufrufe ab) und etwaige Initialisierungssequenzen bereithält. Letztere bereiten Datenstrukturen vor, mit denen die zu testende Unit agieren kann. Einen solchen Prozess zu erstellen, war nicht nur arbeitsaufwendig, sondern setzte auch besonderes Fachkönnen voraus. Und nicht selten verursachte ein solches Testprogramm genau so viel Prüfaufwand wie die zu testende Unit selbst.

Schwerer jedoch wiegt wohl noch die grundlegende Anforderung an Softwaretests an sich: Tests sollen einen objektiven und unabhängigen Blick auf die Software gewährleisten. Dafür ist es jedoch nötig, mit dem Code gut vertraut zu sein. Dies wiederum widerspricht jedoch der geforderten Unabhängigkeit des Prüfprozesses und untergräbt damit die Rechtmäßigkeit des gesamten Vorhabens.

Bei der Entwicklung von Anwendungen für die Medizin- und Bahntechnik sowie für den Luftfahrtsektor sind Unit-Tests als Teil des Entwicklungszyklus seit jeher zwingend vorgeschrieben. Deshalb stammen viele Unternehmen, die derartige Werkzeuge entwickeln, aus dieser Nische. In nicht sicherheitskritischen Bereichen hat sich daher die Meinung verbreitet, Unit-Tests seien zwar an sich eine nette Idee, kommerziell aber nicht zu rechtfertigen. Entscheidenden Anteil an dieser Einstellung hat aber auch der zu Beginn eines jeden Projekts existierende natürliche Optimismus. Man fragt sich, weshalb man in dieser Phase Geld für akribische Unit-Tests ausgeben sollte. Das Team bestehe schließlich aus hervorragenden Entwicklern, das Design sei solide und das Management wäre kompetent – was sollte also schiefgehen?

Die Wahrheit ist jedoch, dass Dinge schiefgehen können und auch tatsächlich schiefgehen. Selbstverständlich bieten auch Unit-Tests keine Erfolgsgarantie. Sie sind jedoch in der Lage, Fehler zu reduzieren. Setzt man sich mit den für schnelle und unkomplizierte Unit-Tests in sicherheitskritischen Systemen konzipierten Werkzeugen auseinander, erscheint es folgerichtig, die gleichen Unit-Tests auch bei jeder Art kommerzieller Software anzuwenden. Denn inzwischen können diese Tools auch die Arbeit jener Entwickler vereinfachen, die in weniger kritischen Bereichen tätig sind. Dazu zählen beispielsweise all jene, die nicht dokumentierten Bestandscode weiterentwickeln müssen. Dies wird wir im Folgenden genauer untersucht.