Das Unit Testing ist eigentlich ein wesentlicher Bestandteil der Codierung. Nur so kann ich direkt überprüfen, ob die Vorgaben der Softwarespezifikation erfüllt sind. Selbst für embedded Systeme kann ich mir eine Simulation der Hardware dazu schreiben, die Vorgaben dann beim Unit Test einstellen und sehen, ob die Logik funktioniert. So kommt für jede geschriebene Funktion eine ganze Reihe an Unit Tests zusammen. Das Ergibt dann eine Test Suite für alle Unit Tests einer Softwarekomponente. Nach jeder Änderung im Code kann dann anschließend die gesamte Test Suite ausgeführt werden. Im Entwicklungsprozeß läuft das dann im Rahmen der „Continuous Integration“ mit Werkzeugen wie Hudson oder Jenkins vollautmatisch nach dem Einchecken der Änderungen ab.
Vorgehensweise
Als Entwicklungsmaschine wird dazu meist ein PC benutzt. Es bietet sich an während der Entwicklung auch gleich die einzelnen Funktionen zu Testen. Dazu muss die Programmlogik der Funktion unter Test von den hardwarenahen Zugriffen über eine API getrennt werden. Es genügt, wenn lediglich die hardwarenahen Zugriffe als „Driver“ herausgekapselt werden. Wird ein Betriebssystem genutzt, müssen auch diese Funktionen herausgekapselt werden. Die Driver Funktionen werden dann als Simulation für die Ausführung der Unittests auf dem PC neu geschrieben. Zusätzlich kommen Funktionen (Control) in diesem Test“Driver“ dazu, die das Verhalten der Hardware festlegen. Damit kann dann jeder Gut- oder Schlechtfall einfach und gefahrlos vorbereitet werden.
Links und Literaturhinweise dazu:
Elecia White
– Making Embedded Systems
ISBN: 978-1-449-30214-6
James W. Grenning
– Test-Driven Development for Embedded C
ISBN: 978-1-93435-662-3
Unittest / Modultest
https://de.wikipedia.org/wiki/Modultest
Testdriven Development
https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung
FCTx
https://github.com/imb/fctx
Bill Hamilton
– Nunit Pocket Reference
http;//nunit.org
http://cppunit.sourceforge.net/doc/cvs/cppunit_cookbook.html
http://sourceforge.net/projects/cppunit/
