Testing and Debugging of Dynamically Composed Applications

Markus Löberbauer

Abstract

Dynamic software composition allows users to reconfigure a program on-the-fly by adding, removing, or swapping sets of components. This requires that every component is dynamically composable, i.e., that it can extend other components and can be extended by other components at run time. To ensure that a component is composable in all possible composition scenarios, testing is necessary, and if an error shows up in a program, developers need debugging support to identify the causing component as well as information about what caused the error.

Current component systems only provide a test harness to host the component under test and recommend test methods, which are usually limited to unit tests of the business logic, whereas the composability of a component is neglected. This is insufficient for dynamically composed programs where every component must work in various composition scenarios.

In this thesis, we present a classification of the composition mechanisms used in current component systems and their contributor provision characteristics (i.e., in what way contributor components are provided to host components). Based on this classification, we present a classification of composability faults that are typical for the composition mechanisms. To find such faults in components, we present the composability test method Act for the Plux composition infrastructure. Act generates test cases for all composition scenarios by varying the order of composition operations, selects a representative subset of test cases so that they are executable in reasonable time, and executes the test cases. Executing a test case means composing the component under test using a given testbed, executing the functional tests, and collecting the occurring composition errors and functional errors. Furthermore, we present the test tool Actor which automates this test method. To find the causes of composability errors in components, we present the debugging method Doc for Plux. Doc records the composition operations of running Plux programs into composition traces, filters the composition traces for relevant components, splits the composition traces into parts with related composition operations, and allows developers to compare traces in order to locate the cause of errors. Moreover, Doc creates hints for possible causes of errors using reasoning and allows replaying the composition from composition traces to visualize the composition state of the program.

This work was funded by the Christian Doppler Research Association and BMD Systemhaus GmbH.

Kurzfassung

Mit dynamischer Komposition können Benutzer ein Programm durch Austausch von Komponenten umkonfigurieren während es läuft. Dazu muss jede Komponente dynamisch komponierbar sein, d.h. sie muss damit umgehen können, dass die Komponente selbst oder andere Komponenten zur Laufzeit hinzugefügt oder entfernt werden. Um sicherzustellen, dass eine Komponente in allen möglichen Kompositionsszenarios komponierbar ist, muss getestet werden. Wenn ein Fehler gefunden wird, soll der Entwickler beim Identifizieren der fehlerhaften Komponente und beim Finden der Fehlerursache unterstützt werden.

Aktuelle Komponentensysteme bieten lediglich eine Testumgebung um die getestete Komponente zu komponieren und empfehlen eine Testmethode, die allerdings nur die Geschäftslogik umfasst, aber die Komponierbarkeit vernachlässigt. Für dynamische Komposition ist das zu wenig, weil jede Komponente in unterschiedlichen Kompositionsszenarios funktionieren muss.

In dieser Arbeit zeigen wir eine Klassifikation von Kompositionsmechanismen und deren Eigenschaften bei der Komponentenbereitstellung. Basierend darauf, zeigen wir eine Klassifikation von typischen Komponierbarkeitsdefekten für die gezeigten Kompositionsmechanismen. Um solche Defekte zu finden, zeigen wir die Testmethode Act für die Plux-Kompositionsinfrastruktur. Act erzeugt Testfälle für alle Kompositionsszenarios durch Variieren der Kompositionsreihenfolge, es wählt eine repräsentative Teilmenge dieser Testfälle, damit diese in vernünftiger Zeit ausführbar sind, und führt sie aus. Einen Testfall auszuführen bedeutet, dass die zu testende Komponente in einer gegebenen Testumgebung komponiert wird, funktionale Tests ausgeführt werden, und die auftretenden Kompositionsfehler sowie die funktionalen Fehler protokolliert werden. Weiters zeigen wir das Testwerkzeug Actor, das die Testmethode automatisiert. Um die Ursache von Komponierbarkeitsfehlern zu lokalisieren, zeigen wir die Debuggingmethode Doc für Plux. Doc zeichnet die Kompositionsoperationen eines laufenden Plux-Programms in einem Protokoll auf, filtert dieses nach relevanten Komponenten, teilt es in Teile zusammengehörender Kom- positionsoperationen und ermöglicht Entwicklern diese Protokollteile zu vergleichen und damit die Fehlerursache einzugrenzen. Außerdem erzeugt Doc Hinweise auf mögliche Fehlerursachen und ermöglicht das schrittweise Abspielen von Kompositionsprotokollen, um den Kompositionszustand des Programms zu visualisieren.

Diese Arbeit wurde von der Christian Doppler Forschungsgesellschaft und von BMD Systemhaus GmbH gefördert.

PhD thesis, Johannes Kepler University Linz, Oktober 2012