Erfahrungen mit Unittests [C, AVR]

tester schrieb:

> den Artikel Unittests mit uCUnit angeschaut.

Mein Verständnis von Unit-Tests ist ein anderes, als das welches in 
diesem Artikel suggeriert wird. Insbesondere das Beispiel mit der 
Flugzeuglandung ist für mich eben kein Unittest sondern ein ganz 
normaler Algorithmus, der beschreibt welche Aktionen zum Beginn einer 
Landung durchzuführen sind.

Ein Unittest, so wie ich den Begriff verstehe, wäre am Beispiel 
Fleugzeug: Wenn der Mechaniker in der Werft ein Gerät an die 
Fahrwerkselektronik anschliesst, welches das Fahrwerk unter 
verschiedensten Bedingungen (Hydraulikausfall, nur Notstrom vorhanden 
etc) versucht ein und auszufahren und feststellt ob es dabei jeweils in 
der sicheren Ausfahrposiiton einrastet.
Ist der Unittest abgeschlossen, wird das Prüfgerät wieder abgeklemmt 
(fliegt also nicht mit) und damit ist der Unittest abgeschlossen.

D.h. Unittests kommen während der Software-Entwicklung zum tragen, 
werden aber nicht mit dem Endprodukt ausgeliefert.

> Wie sieht das in der Praxis mit Speicher und Laufzeit aus? Machen die
> Prüfungen Sinn oder ist es besser, von "Hand" zu prüfen?

Diese Frage stellt sich für mich so gar nicht. Es ist das Wesen eines 
Unittests, dass jede Unit (jedes Modul) unabhängig von allen anderen, 
nur für sich getestet wird. Das kann sein, indem man die möglichen 
Wertebereiche der Eingangsvariablen durchspielt und sich die Reaktion 
der Unit auf jeden einzelnen Fall ansieht. Das kann auch sein, indem man 
vorhergehende Fehlerfälle sammelt und auf die Unit loslässt, etc.

Aber: Nachdem eine Unit getestet wurde und diese den Test überstanden 
hat, ist der Unittest dafür abgeschlossen und wird ev. während der 
Weiterentwicklung des kompletten Produkts wieder stillgelegt. D.h. die 
Frage nach Laufzeitverhalten bzw. Speicher stellt sich so gar nicht, da 
ich den Test jederzeit abschalten kann ohne das Verhalten des kompletten 
Programms zu beeinflussen. Oft ist ein Unittest auch ein völlig anderes 
Programm, welches nur diese eine Komponente einbindet und diese durch 
die automatische Testsequenz durchlaufen lässt.

> Es geht mir wie gesagt vor allem um Erfahrungen.

Ich hatte lange Jahre an einem CAD System gearbeitet. In dessen 
Geometrie-Kern habe ich Testfunktionen eingearbeitet, die im DEBUG Modus 
die komplette Geometrie nach jeder High-Level Operation nach 
Inkonsistenzen durchforstet hat (dangling Pointer, Counter die nicht 
stimmen, Bounding Boxen die nicht nachgerechnet wurden, etc). Die Anzahl 
der Geometrie-Fehler, die das Pgm zum abschmieren brachten, sind mit 
Einführung dieser Tests schlagartig gegen 0 gesunken. Laufzeit: Etwa 3 
mal so langsam wie ohne Test. Ist aber wie gesagt irrelevant, da sie der 
Endbenutzer nie zu Gesicht bekommen hat, da nur in der DEBUG Version 
mitcompiliert.

Einen echten Unit-Test, in obigen Sinne, habe ich zb. für manche Matrix 
Operationen gemacht. ZB. gibt es eine Funktion, die eine Matrix in 3 
erzeugende Euler Winkel zerlegt. Da die Berechnung umfangreich ist und 
numerische Probleme zu erwarten waren, hat der UnitTest dafür so 
ausgesehen, dass 3 Winkel in 0.01 Grad inkrementiert wurden, daraus 
jeweils die zugehörige Matrix errechnet wurde und diese Matrix wieder in 
die Winkel zerlegt wurde. Das Ergebis davon wurde mit den originalen 
Winkeln verglichen. Ein derartiger Unittest muss logischerweise nur 
solange ablaufen, bis das Ergebnis entspricht. Danach wird er still 
gelegt, solange nicht begründeter Verdacht besteht, dass sich jemand an 
der Funktion vergriffen hat und sie verschlimmbessert hat.