Systematisches Vorgehen

Alle Tests mit diesem Makro sind übrigens grafische Anwendungen und benötigen X. Sollen sie automatisch ablaufen, empfiehlt es sich, sie in einem vorgetäuschten X-Server zu starten. Dafür eignet sich das Tool Xvfb. Der Aufruf »xvfb-run -a Anwendung« führt sie im simulierten X aus. Die Schreibweise gelingt aber nicht bei allen Distributionen [6]. Schließlich fügen die Zeilen in Listing5 den Test in das Cmake-Projekt ein.

Abbildung 4: Die Anwendung besteht aus den Klassen 1 und 2, deren Funktion die beiden Testklassen prüfen.

Wenn der Programmierer den GUI-Test fertiggestellt hat, startet er zwei Programme und überwacht deren Ausgabe. Bei einer größeren Anwendung erhöht sich ihre Anzahl schnell und das Ausführen gestaltet sich zeitraubend und unübersichtlich.

01 SET(test_CPP
02   testhexspinbox.cpp
03   ../hexspinbox.cpp
04   ../memorymapmodel.cpp
05   ../domitem.cpp
06 )
07 QT4_AUTOMOC(${test_CPP})
08 ADD_EXECUTABLE(testhexspinbox ${test_CPP})
09 TARGET_LINK_LIBRARIES(testhexspinbox ${QT_LIBRARIES})

Abhilfe schafft dann das Tool Ctest, da es die Testausführung stark vereinfacht. Wie Abbildung4 verdeutlicht, führt Ctest die einzelnen Testanwendungen nacheinander aus und sammelt deren Ausgaben. Damit ist der Funktionsumfang des Werkzeugs noch nicht erschöpft: Die Möglichkeit, Ctest auch ohne Cmake einzusetzen, macht es daher auch für solche Projekte interessant, die dieses Buildtool nicht einsetzen.

01 IF(BUILD_TESTING)
02   ADD_SUBDIRECTORY(tests)
03 ENDIF(BUILD_TESTING)

01 ADD_TEST(TestMemoryMapModel ${EXECUTABLE_OUTPUT_PATH}/testmemorymodel)
02 ADD_TEST(TestHexSpinBox ${EXECUTABLE_OUTPUT_PATH}/testhexspinbox)

01 IF(BUILD_DEBUG)
02   SET(CMAKE_CXX_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fprofile-arcs -ftest-coverage")
03   SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fprofile-arcs -ftest-coverage")
04 ENDIF(BUILD_DEBUG)

Weil das Beispiel Cmake einsetzt, integriert sich Ctest besonders einfach. Die Anweisung »include(Ctest)« – in der Datei »CMakeLists.txt« im obersten Verzeichnis gleich unter »cmake_minimum_required« – bindet Ctest in das Projekt ein. Die damit verfügbaren Erweiterungen im Makefile zeigen sich bei Kdevelop sofort im »Projekte« -Reiter. Innerhalb von Cmake steht dadurch die Option »BUILD_TESTING« bereit, die sich anbietet, um Tests ein- und auszuschalten. Dabei zeigt sich der Vorteil, die Tests in ein separates Verzeichnis auszugliedern, womit die Anweisungen in Listing6 die Tests aktivieren und deaktivieren.

Geordnete Binaries

Schließlich benötigt Cmake noch den Hinweis, welche Anwendung ein Test ist und welche nicht. Diese Aufgabe löst die Anweisung in Listing7 aus der »CMakeLists.txt« im Verzeichnis »tests« . Damit Ctest die ausführbare Anwendung auch findet, enthält der Befehl neben der Anwendung selbst auch den Pfad. Dabei kommt die Variable »${EXECUTABLE_OUTPUT_PATH}« zum Einsatz, die das oberste »CMakeLists.txt« definiert. Sie sorgt dafür, dass sich bei Abschluss der Übersetzung alle ausführbaren Dateien in diesem Ordner befinden. Sinnvoll ist meist die Wahl »${CMAKE_BINARY_DIR}/bin« , wodurch Cmake sie in den Ordner »bin« im Buildverzeichnis verschiebt.

Nach erneutem Durchlauf der Konfiguration mit »cmake ../« im Buildverzeichnis genügt es, »make test« oder »Ctest« aufzurufen, um alle Tests zu starten. Dabei ruft der Makeprozess die Tests nacheinander auf und gibt ihre Ausgaben zusammengefasst aus. Den damit verbundenen Verlust von Details verhindert die Option »-V« , womit Ctest die Originalausgabe für jeden Test anzeigt. Da dies bei einer größeren Anzahl von Tests unübersichtlich ist, bietet sich die Option »-R Test« an. Sie weist Ctest an, nur diesen Test auszuführen. Will der Entwickler die Tests auch weiterhin in Xvfb ablaufen lassen, startet er Ctest damit.

Diese einfachere Testausführung schöpft Ctest nicht aus. Um von seinen Vorteilen zu profitieren, nutzt der Tester die so genannten Dashboard-Tests, die Daten sammeln und an eine zentrale Aufbereitungseinheit wie Cdash übermitteln [7]. Zudem bieten sie weitere Vorteile, weshalb sich der Einsatz der angebotenen Dashboard-Tests auch ohne Dashboard lohnt (Abbildung5). Für verschiedene Testkategorien bietet Ctest die drei Testszenarien Continuous, Nightly und Experimental an. Ersteres ist dafür gedacht, nach jeder eingecheckten Version die Tests zu durchlaufen und so Fehler und seine Verursacher sofort zu entdecken.

Abbildung 5: Cdash gliedert die Ctest-Ergebnisse nach Szenarien: Es fasst jeden Lauf mit Hostnamen und Plattform zusammen und ergänzt sie durch die Werte der Testabdeckung und Speichertests (Dynamic Analysis). Per Mausklick sind Details zu Compiler-Meldungen und zeilengenaue Ansicht der Testabdeckung erreichbar.