UnitTests mit (Win)AVR

[schmiereck]

Hallo,

hat jemand schon Unit-Tests für AVR Programme entwickelt oder weiss einen Hinweis darauf, wie das geht?
Natürlich in C, bei mir momentan C++, aber das dürfte kein Rolle spielen.

Aus momentanter Sicht schiene es mir sinnvoll diese in einem Emulator ablaufen zu lasen. Hier habe ich die Stichworte AVaRICE und SimulAVR gefunden, allerdings muss ich Zugeben diese noch nicht getestet zu haben.

Konkretes Ziel wäre es, für bestimmte Funktionen eines RP6 Projektes, einzelne Funktionen als Unit-Test aufrufen zu können. Diese müssen nicht auf die zpezifische Hardware des Roboters bezogen sein, reine Logik Überprüfungen würden reichen.

Grüße,
smk

[KingNothing]

Hi,
hab schon mal einige versuche in diese Richtung unternommen (allerdings nur in C). Simavr (http://gitorious.org/simavr) eignet sich eigentlich ganz gut für diese Zwecke, da man, im Gegensatz zu simulavr 100%tige Kontrolle über die E/A sowie das Timing hat.

Allerdings sind meine Versuche noch nie über einfache PORTA.1 schaltet PORTB.1 herausgegangen.

Einen anderen Ansatz hat wesen von ruin&wesen (http://ruinwesen.com/blog?id=1148) verfolgt: Er hat für alle Tests Mock-Objekte programmiert, die das Verhalten von der Hardware nachbilden.
Eigentlich ganz einfach - ich stelle mir das nur schwierig in Sachen Timing etc.[/url]

HTH

[MrWhite]

hat jemand schon Unit-Tests für AVR Programme entwickelt oder weiss einen Hinweis darauf, wie das geht?
Natürlich in C, bei mir momentan C++, aber das dürfte kein Rolle spielen.

Zu einem Unit-Test gehört von Anwenderseite ja nicht viel dazu. Im Prinzip sind das ja normale Tests mit ganz normalen Code. Wenn Logik-Überprüfungen ausreichend sind, dann pack doch deine Tests einfach in Funktionen/Methoden die als return type boolean haben und schreib eine Testroutine die alle Funktionen durchgeht.

Mehr sind Unit Tests ja wirklich nicht.

Das so viel Trara darum gemacht wird, liegt vor allem daran, dass diese Tests in den Buildzyklus integriert werden können, also automatisiert statt finden, und wertvolle Informationen wie Code Coverage etc. liefern (was mit C als meist nativ-kompilierende Sprache ohne Metainformationen aufgrund der Compilervielfalt nicht ganz so einfach sein dürfte).

Als einzelner Mikrocontroller-Entwickler braucht man kein ganzes Build-System.

Unit-Tests werden oft zusammen mit Mock-Frameworks genutzt, die wohldefinierte Schnittstellen nachahmen. Dies ist im wesentlichen Code-Generierung zur Laufzeit.

Hier gibt es CUnit, damit sollte jegliche Logik testbar sein.

[schmiereck]

Ich kann Deine Argumentation nachvollziehen. Als ich die ursprüngliche Frage gestellt habe, ging es mir aber hauptsächlich um um das testen von Funktionen außerhalb des Mikrocontrollers, also wohl am besten in einem Emulator oder mit einem Crosscompiler auf dem Entwicklungssystem.

Der Ablauf den des Uploads der Tests auf den Mikrocontroller, starten, Ergebnisse aus einem Terminalfenster lesen, gegebenfalls nachbessern und dann alles von vorne ist schon etwas mühsam.

Und eine wichtige Anforderung, die Du vergessen hast anzugeben, ist - Unit-Tests sollen möglichst oft ausgeführt werden.

Wobei ich wirklich nicht daran gedacht habe die Tests in den Buildzyklus zu integrieren, sonderen sie eben eher als Testumgebung bei der Entwicklung von Funktionen zu nutzen. Es ging mir also um einen einfachen Aufruf und einübersichtliches Ergebnis.

Gruß,
smk

[MrWhite]

Wenn du eh C verwendest und kein ganzes Framework verwenden willst: Function-Pointers sind deine Freunde.

Das ganze bleibt auch absolut wiederverwendbar und flexibel einsatzfaehig wenn du deine Schnittstellen schoen definierst.