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
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.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.