Autor: Franco Chiappori, Schindler Aufz\u00fcge AG<\/p>\n
Continuous Integration und automatisierte Tests sind erprobte Mittel, um die Qualit\u00e4t von Software zu f\u00f6rdern. Gerade den automatisierten Unit-Tests kommt gro\u00dfe Bedeutung zu, garantieren sie doch als Basis der Testpyramide auch die Basis der Qualit\u00e4t. Als Entwickler sch\u00e4tzt man zudem die schnellen Feddbackzyklen von Unit-Tests. In der Praxis fangen die Probleme aber oftmals schon beim Isolieren des zu testenden Codes an. Wie l\u00f6se ich meine C++ Klasse oder meine C Funktion aus ihren Abh\u00e4ngigkeiten?<\/strong><\/p>\n Die Testpyramide in Abb. 1 (siehe\u00a0PDF<\/a>) zeigt, wie eine Applikation idealerweise durch Tests abgedeckt wird [1]. Die Basis bilden Unit-Tests, welche eine kleine Software-Einheit \u00fcberpr\u00fcfen. Schl\u00e4gt ein solcher Test fehl, kann das Problem nur in der getesteten Unit liegen. Unit-Tests sind meist einfach zu erstellen, k\u00f6nnen innerhalb weniger Sekunden ausgef\u00fchrt werden und gefundene Fehler k\u00f6nnen leicht lokalisiert werden. Daher sollte der gr\u00f6\u00dfte Teil der Funktionalit\u00e4t durch Unit-Tests abgedeckt werden. Ein Unit-Test bedingt jedoch, dass der entsprechende Code isoliert wird.<\/p>\n Die verschiedenen Ans\u00e4tze zur Isolation lassen sich am besten mit einem konkreten Beispiel aufzeigen. Im vorliegenden Projekt werden bin\u00e4re Daten \u00fcber eine UART-Schnittstelle kommuniziert. Um die einzelnen Meldungen abzugrenzen, wird das Framing des Point-to-Point Protokoll (siehe Abb. 2,\u00a0PDF<\/a>) eingesetzt [2]. Grob zusammengefasst:<\/p>\n Ein solches Framing l\u00e4sst sich einfach in Code umsetzen. Abb. 3 (siehe\u00a0PDF<\/a>) zeigt eine m\u00f6gliche Implementierung in C. Diese ist simpel und direkt, l\u00e4sst sich aber nur schwer f\u00fcr Unit-Tests isolieren, da sie direkt auf den UART-Treiber zugreift (uart_put).<\/p>\n Eine bew\u00e4hrte Methode, um diese Problem zu umgehen, ist Dependency Injection. Der Framing-Code ben\u00f6tigt ein zeichenorientiertes Device, an das die codierten Bytes weitergereicht werden k\u00f6nnen. Wenn man diese Abh\u00e4ngigkeit von au\u00dfen vorgibt (bildlich gesprochen einimpft), spricht man von Dependency Injection. Abb. 4 (siehe\u00a0PDF<\/a>) zeigt eine m\u00f6gliche Implementierung in C++.<\/p>\n Mit dieser Erweiterung l\u00e4sst sich der Code relativ einfach isolieren. Anstelle des UART wird beim Unit-Test ein sogenanntes Mock-Objekt mitgegeben. Dieses Objekt implementiert die Device-Schnittstelle, aber speichert die geschriebenen Zeichen, damit sie vom Unit-Test inspiziert werden k\u00f6nnen. Abb. 5 (siehe\u00a0PDF<\/a>) zeigt das zugeh\u00f6rige Klassendiagramm, ein m\u00f6glicher Unit-Test ist in Abb. 6 (siehe\u00a0PDF<\/a>) aufgelistet.<\/p>\n Mit Hilfe von Dependency Injection und Mock-Objekten lassen sich Abh\u00e4ngigkeiten durchbrechen, und nahezu jeder Code kann f\u00fcr Unit-Tests isoliert werden. Doch die Bedeutung von Dependency Injection geht weit \u00fcber das Thema Unit-Test hinaus. Im Prinzip geht es darum, einzelne Problembereiche zu trennen (Separation of Concerns). Das Framing an sich hat nichts mit dem UART zu tun. Dank Dependency Injection k\u00f6nnen diese Aspekte auch im Design sauber getrennt werden.<\/p>\n Diese Vorteile haben aber einen gewissen Preis. Durch die zus\u00e4tzliche Abstraktion geht Kontextinformation verloren. Es ist nicht mehr auf den ersten Blick ersichtlich, wozu das Framing eingesetzt wird. Zudem muss mehr Code erstellt, dokumentiert und gewartet werden. Im vorliegenden Beispiel ist das nicht viel, aber in einem echten Projekt gibt es hunderte von Abh\u00e4ngigkeiten, und entsprechend viele Schnittstellen m\u00fcssen abstrahiert werden. F\u00fcr den Unit-Test an sich ergibt sich auch ein gewisser Aufwand, die Mock-Objekte m\u00fcssen implementiert und aufgesetzt werden.<\/p>\n Wie im Unit-Test Code von Abb. 6 (siehe\u00a0PDF<\/a>) ersichtlich, bedeutet der Einsatz von Mock-Objekten immer einen gewissen Aufwand und macht den Test komplexer. Man kann umgekehrt fragen: Welcher Code l\u00e4sst sich m\u00f6glichst direkt und ohne Aufwand testen? Die Antwort ist nicht schwer: Reine Funktionen ohne Abh\u00e4ngigkeiten und Seiteneffekte sind am einfachsten zu testen. Der Output h\u00e4ngt nur vom Input ab, und es gibt keine Abh\u00e4ngigkeiten, die uns das Leben schwermachen.<\/p>\n Wenn Code aus diesem Blickwinkel betrachtet wird, kann man oft feststellen, dass Klassen und Funktionen zwei Aspekte haben. Zum einen eine Kernlogik, welche die Verarbeitung von Daten und Events festlegt. Zum anderen eine Vernetzung, welche den Code mit seiner Umwelt verkn\u00fcpft. Im Framing Beispiel ist die Kernlogik das Erstellen des Frames, w\u00e4hrend die Verkn\u00fcpfung das Weiterleiten an den UART ist. Diese zwei Aspekte lassen sich trennen, wie in Abb. 7 (siehe\u00a0PDF<\/a>) gezeigt.<\/p>\n Durch diese Trennung entf\u00e4llt das Mock-Objekt und der Unit-Test wird vereinfacht (Abb. 8, siehe\u00a0PDF<\/a>). Der Code f\u00fcr die Vernetzung ist oft so banal, dass kein eigener Unit-Test n\u00f6tig ist. Dieser Ansatz ist auch als Humble Object Pattern bekannt [3].<\/p>\n Im vorliegenden Projekt wurde zun\u00e4chst Kernlogik und Vernetzung wie in Abb. 7 (siehe\u00a0PDF<\/a>) getrennt. Performance-Messungen auf dem Zielsystem ergaben jedoch, dass dieser Code bei weitem zu langsam war. Neben anderen Faktoren kostete das mehrfache Kopieren der Daten und der Funktionsaufruf f\u00fcr jedes gesendete Byte zu viel Zeit. Man war gezwungen, die Logik in die Treiberschicht zu verschieben. Nach mehreren Optimierungsschritten sah der Treibercode wie in Abb. 9 (siehe\u00a0PDF<\/a>) aus.<\/p>\n Dieser optimierte Code stellt dem Unit-Test drei H\u00fcrden in den Weg. Erstens wird der Treibercode auf dem PC nicht mitkompiliert. Zweitens kollidieren Definitionen im referenzierten\u00a0registers.h\u00a0<\/span>mit anderen Header-Dateien. Drittens werden Daten direkt in UART Register geschrieben: die Adresse von\u00a0UartaRegs.txFifo\u00a0<\/span>entspricht auf dem Target der Registeradresse des Sende-FIFO.<\/p>\n Der erste L\u00f6sungsansatz war es, den Treibercode f\u00fcr den Unit-Test zu patchen. Mit einem gezielten Patch wurden das\u00a0#include<\/span>\u00a0abge\u00e4ndert sowie die direkten Zugriffe auf die UART Register durch Funktionsaufrufe ersetzt. Das resultierende File wurde auf dem PC kompiliert und getestet. Vorteil dieses Ansatzes ist, dass man den Treibercode beliebig manipulieren kann, um ihn testf\u00e4hig zu machen. Auf der anderen Seite gibt es auch viele Nachteile. Wird der Treibercode ge\u00e4ndert, muss der Patch angepasst werden. Da Codeteile ersetzt werden, k\u00f6nnen Fehler verdeckt werden. In der Praxis stellte sich heraus, dass die Tests br\u00fcchig waren und immer wieder geflickt werden mussten.<\/p>\n Ein zweiter L\u00f6sungsansatz besteht darin, das Source-File des Treibers im Unit-Test zu inkludieren. So wird die erste H\u00fcrde, das Mitkompilieren des Treibercodes, \u00fcberwunden. Um die zweite H\u00fcrde zu nehmen, kann das\u00a0#include<\/span>\u00a0im Treiber an eine Bedingung angekn\u00fcpft werden (siehe Abb. 10,\u00a0PDF<\/a>). Im regul\u00e4ren Code wird das Symbol\u00a0UNIT_TEST<\/span>\u00a0nie definiert, und\u00a0registers.h<\/span>\u00a0wird inkludiert. Im Unit-Test kann dieses Symbol definiert werden, um das\u00a0#include<\/span>\u00a0zu unterdr\u00fccken.<\/p>\n Technisch am interessantesten ist die dritte H\u00fcrde. Wie kann der Zugriff auf eine Variable abgefangen werden? Der zu testende Code schreibt w\u00e4hrend einem Aufruf mehrfach auf das Register, und der Test muss nicht nur das letzte Byte, sondern alle geschriebenen Bytes kennen. Hier kommt C++ und seine m\u00e4chtigen Sprachmittel zu Hilfe. Es wird eine Klasse\u00a0FakeFifo<\/span>\u00a0definiert, die den Zuweisungsoperator f\u00fcr uint8_t \u00fcberschreibt. Anschlie\u00dfend kreiert man ein Objekt von diesem Typ unter\u00a0UartaRegs.txFifo<\/span>, so dass der Treibercode auf das\u00a0FakeFifo<\/span>\u00a0schreibt. Abb. 11 (siehe\u00a0PDF<\/a>) zeigt den gesamten Code, inklusive eines Unit-Tests.<\/p>\n Mit diesem Ansatz kann der originale Treibercode mit minimalsten Anpassungen ausgiebig getestet werden. Das funktioniert auch in die andere Richtung, wenn Daten aus einem FIFO Register gelesen werden. Hierzu muss die Klasse\u00a0FakeFifo<\/span>\u00a0den Umwandlungsoperator f\u00fcr uint8_t \u00fcberschreiben.<\/p>\n Mit ein paar kleinen Tricks aus der Schatulle von C\/C++ l\u00e4sst sich auch hardwarenaher und laufzeitkritischer C-Code effizient testen. Auf Stufe Unit-Test kann so die Logik auf Herz und Nieren gepr\u00fcft werden. F\u00fcr weniger laufzeitkritischen Code empfiehlt sich das Humble Object Pattern, um Kernlogik und Vernetzung zu trennen. Dies f\u00fchrt zu verst\u00e4ndlichem und leicht testbarem Code. All diese Techniken erm\u00f6glichen es, die Testabdeckung zu erh\u00f6hen. Eine Abdeckung von 100% kann nicht erreicht werden, aber, um es mit den Worten von Martin Fowler zu sagen [4]: „Es ist besser, unvollst\u00e4ndige Tests zu schreiben und laufen zu lassen, als vollst\u00e4ndige Tests bleiben zu lassen“.<\/p>\n [1]\u00a0 Mike Cohn:\u00a0Succeeding with Agile<\/em>. Addison-Wesley, 2009 Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualit\u00e4t & Debug.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Test, Qualit\u00e4t & Debug steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nStandardansatz Dependency Injection<\/h2>\n
\n
Mock-Objekte vermeiden durch Trennung von Kernlogik und Vernetzung<\/h2>\n
Herausforderungen beim Test von laufzeitkritischem Treibercode<\/h2>\n
L\u00f6sungsansatz Treibercode patchen<\/h2>\n
L\u00f6sungsansatz Source-File inkludieren<\/h2>\n
Fazit<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
\n[2]\u00a0 W. Simpson, Editor:\u00a0RFC1662, PPP in HDLC-like Framing<\/em>. IETF, July 1994
\n[3]\u00a0 Gerard Meszaros:\u00a0xUnit Test Patterns<\/em>. Addison-Wesley, 2007
\n[4]\u00a0 Martin Fowler:\u00a0Refactoring<\/em>. Addison-Wesley, 1999<\/p>\n
\nTest, Qualit\u00e4t & Debug – unsere Trainings & Coachings<\/h2>\n
\nTest, Qualit\u00e4t & Debug -Fachwissen<\/h2>\n