Qualitätssicherung für Embedded-Linux-Projekte Unit-Tests mit Open-Source-Werkzeugen

Library-Tests

Wie die Bezeichnung Makefile.am schon suggeriert, ist es möglich, Test- Code mit der Bibliothek unter test zu binden. Mit von libtool erzeugten Bibliotheken wurde bis jetzt noch nicht entschieden, ob es sich hierbei um eine statische oder Shared Library handelt. Die entsprechenden Maßnahmen werden zum Zeitpunkt der Konfiguration durchgeführt. Library-Test-Code ist ähnlich zu normalen Funktionstests. Zusätzlich enthält der Code Stress-Tests für die Library, der im erfolgreichen Testfall laufen gelassen wird und prinzipiell nicht spezifisch ist für den Fall des Library-Tests.

Der Test von statischen Funktionen in normalem Code ist schwierig zu bewerkstelligen, weil Test-Code und Produktiv- Code nicht in Wechselwirkung zueinander treten sollen. Da es aber nicht gewünscht ist, den Produktiv- Code für Testzwecke abzuändern, muss hier einer von mehreren möglichen „Workarounds“ angewendet werden. Eine Möglichkeit ist die Einbeziehung der C-Quelldatei in den Test- Code durch

#include „../src/hello.c“

Diese Konstruktion ist nicht gerade eine allgemein vorgesehene Nutzung des C-Pre-Prozessors. Aber in diesem Fall funktioniert es sehr gut. Es muss nur darauf geachtet werden, dass die eingebundene C-Datei keine eigene main()-Funktion enthält und dass andere inkludierte Dateien mit dieser Konstruktion zusammenarbeiten.

Wie im Library-Testbeispiel oben gesehen, bietet die Bibliothek autounit eine gute Grundlage, um Stress-Tests anstelle normaler Tests durchzuführen. Die entsprechenden Tests werden genau n-mal durchgeführt, wobei n in au_run_stress_suite() spezifiziert wird.

Da der Quellcode nicht komplett aus C-Code besteht, können Testprogramme laufen gelassen werden, die als Shell-Skripte oder in anderen Sprachen vorliegen. Definiert im Makefile.am, müssen die entsprechenden Dateien nur in der Variable TESTS aufgelistet werden. Danach laufen sie automatisch mit den anderen Tests durch. Bei der Implementierung sollte aber darauf geachtet werden, dass das Programm auf dem Embedded-Target laufen soll. Das Beispiel-Paket enthält ein Skript namens test-test, welches running on ‘hostname’... in stdout schreibt.

Verbindung mit dem Target-System

Wie im Makefile.am angegeben, definiert die Variable TESTS_ENVIRONMENT eine SSH-Verbindung (verschlüsselte IP-Netzwerkverbindung) für die Verbindung zum Target-System. Um „make check“ davon abzuhalten, nach einem Passwort beim Login auf dem Target zu fragen, muss die „Public Key Authentication“ auf dem Target-System aktiviert werden. Eine detaillierte Schritt-für-Schritt- Beschreibung ist in der Datei Readme im Beispiel tarball enthalten. Wenn alles korrekt eingerichtet ist, sollte der Lauf von make check in etwa zu dem in Listing 4 gezeigten Resultat führen.

Interessant hierbei ist, dass der individuelle Output des Tests vom Target- System stammt, mit Ausnahme von PASS: Diese Zeilen sind auf dem Horst erzeugt worden. Die Statistiken („All 4 tests passed“) haben ihren Ursprung auf dem Entwicklungs-Host. Ereignet sich bei den Testdurchläufen ein Fehler, so ist der Output selbsterklärend – anstelle von „All 4 tests passed“ erscheint „x of 4 tests failed“ mit entsprechender Angabe bei den Einzeltests, welcher Schritt den Fehler verursachte.