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

Unit-Tests mit Open-Source-Werkzeugen

Das Aufsetzen eines Projekts oder Packages mit GNU autotools ist relativ einfach. Allerdings kann man nicht behaupten, dass es auch überall gut beherrscht wird. Hier ist es oft hilfreich, die Dokumentationen der entsprechenden Pakete aufmerksam zu studieren. Ein simples Beispiel hierfür ist im nachfolgenden Kapitel dargestellt.

Zu Beginn kann autoscan eine configure. ac herstellen, indem man diese von configure.scan umbenennt. Das Makefile.am kann so einfach aussehen:

bin_PROGRAMS = helloworld

Angenommen, es wurden eine configure. ac und einige Makefile.am erstellt, sollten im nächsten Schritt Tests für den eigentlichen Code geschrieben werden. Im Idealfall werden diese Tests sogar vor dem eigentlichen Programm- Code erstellt. Jedoch, selbst wenn man mit aller Kraft versucht, dieses Ziel zu erreichen, wird man in der Realität nicht umhin können, eine gewisse evolutionäre Dynamik im Rahmen des Entwicklungsprozesses zu berücksichtigen, die einen davon abhält, wirklich alle Tests vor der „echten“ Code-Erstellung entwickelt zu haben.

Integration der Testfälle in die Code-Basis

Zur besseren Unterstützung des Entwicklers verfügt automake bereits über einige Eigenschaften zur Integration von Tests in die Code-Basis. Das Auflisten von Executable-Dateien in der Variablen TESTS in Makefile.am macht automake auf den Umstand aufmerksam, dass bereits Tests im jeweiligen Verzeichnis lokalisiert sind. Automake wird sodann die erforderlichen Regeln für einen einfachen make check zum Zeitpunkt des Builds erzeugen. Es ist möglich, die Tests zusammen mit dem eigentlichen Quellcode des Projekts zu integrieren, beispielsweise, indem das gleiche Verzeichnis genutzt wird. Genauso gut kann der Test-Code aber auch in einem separaten Verzeichnis gepflegt werden, was die empfehlenswertere Methode darstellt. Auf diese Weise ist der Test-Code klar vom eigentlichen Programm-Code getrennt, wodurch vermieden wird, dass Test- Code mit Produktiv-Code installiert wird.

All diese Vorkehrungen treffen normalerweise nicht so sehr auf die Entwicklung von Embedded-Software zu, da hier die Programme auf einem anderen System ausgeführt werden, als das, auf dem sie entwickelt wurden. Obwohl GNU autotools eine Cross- Compilierung erkennt, beherrscht automake nicht die Ausführung eines Programms auf einem Remote-Host. Vielleicht ist dies dem Umstand geschuldet, dass Embedded-Entwicklung zu vielfältig ist, was an zahlreichen komplett verschiedenartigen Ansätzen zur Compilierung, dem Host-Target Setup und anderen Dingen zu erkennen ist. Immerhin haben die Autoren von automake eine Variable vorgesehen, die für das Setup einer Host-Target- Verbindung zu Testzwecken verwendet werden kann: TESTS_ENVIRONMENT. Inklusive des Aufsetzens von Variablen spezifiziert es den Befehl zum Ausführen des Testprogramm- Aufrufs anstelle von /bin/sh. Das ermöglicht eine Verbindung zum Target via SSH mit:

TESTS_ENVIRONMENT = ssh username@targethost

Hierbei handelt es sich um die spezielle Syntax des Makefiles zum Einbinden einer Variablen. Die konkreten Werte dieser Variablen können sich in der Realität unterscheiden, z.B. hinsichtlich Einstellungen für die entsprechende Target-Umgebung. Wichtig ist, dass das Kommando zur Ausführung als Argument bereitgestellt wird, so dass SSH das entsprechende Testprogramm auf dem Target ausführen kann.

Neben SSH, das eine Netzwerkverbindung erfordert, kann auch eine serielle Verbindung zum Target genutzt werden. Die einzigen zwingenden Maßnahmen sind das automatische Deployment des gerade compilierten Test-Codes zum Target, die dortigen Programmaufrufe und Auswerten des Return-Wertes und der Standardausgabe. Während im geschilderten Beispiel dies simpel über NFS und SSH bewerkstelligt wird, kann ebenfalls relativ einfach eine Client-Server-Infrastruktur implementiert werden, die diese Funktionalität über unterschiedliche Verbindungswege liefert. Einen weiteren Ansatz könnte eine Netzwerkverbindung mittels serieller Leitungen oder USB darstellen.

Für den Fall, dass die Dateien via NFS exportiert werden, ist es am besten, die gleiche Verzeichnis-Hierarchie sowohl für Entwicklungs-Host als auch für das Target zu wählen. So ist es nur noch nötig, auf dem Target in das gleiche Verzeichnis zu wechseln wie auf dem Host und dort dieselben Programme auszuführen wie auf dem Host.