Erfahrungen mit Unittests [C, AVR]

[tester (Gast)]

Hallo,

hat jemand von euch schon Erfahrungen mit Unittests auf AVRs gemacht?

Ich habe mir den Beitrag "Teststrategien für Embedded Devices" und 
den Artikel Unittests mit uCUnit angeschaut.
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?

Es geht mir wie gesagt vor allem um Erfahrungen.

mfg tester

[Karl H. (kbuchegg)]

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.

[tester (Gast)]

Mit Unittests meine ich Frameworks für "testgetriebene Entwicklung"
von Software, siehe 
http://de.wikipedia.org/wiki/Testgetriebene_Entwicklung

Es geht nicht um Systemstests, die unabhängig vom Produktionscode 
geschrieben und ausgeführt werden.

> 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.

Genau das widerspricht dem testgetriebenen Entwickeln.

Dort wird der Testfall vor dem Produktivcode geschrieben (test-first). 
Damit ist eine hohe Testdichte gewährleistet. Der Test verbleibt im 
Produktivsource.

Dadurch ist es auch möglich, einen Test zu schreiben, dessen Source noch 
nicht geschrieben ist (Einfluss/Seiteneffekte auf Komponenten). 
Testfälle können auch unabhängig voneinander spezielle Komponente 
testen.

D. h. bei Weiterentwicklungen, gerade durch Dritte, ist ein konsistentes 
System nach den (Test-)Spezifikationen gewährleistet.

> Einen echten Unit-Test, in obigen Sinne
> ...
> Danach wird er still gelegt, solange nicht begründeter Verdacht
> besteht, dass sich jemand an der Funktion vergriffen hat und sie
> verschlimmbessert hat.

Darum geht es bei den Unittests. Änderungen oder Refactoring des Sources 
können somit getestet werden, ob das Verhalten der in den Tests 
programmierten Spezifikation entspricht.


Ich kann mir selbst gut vorstellen, dass solche Unittests gut auf PC, 
vielleicht auch auf 32-µC umsetzbar sind.

Meine Frage ist halt, ob jemand damit bei 8-Bittern Erfahrungen gemacht 
hat.

Mfg tester