Intelligenter Softwaretest mit dem DeepSampler

DeepSampler ist eine Entwicklungsbibliothek und erlaubt es, beliebig große Softwaresegmente für Testautomatisierungen zu isolieren. Bei Softwaretests bietet er eine Zwischenlösung zwischen JUnit-Tests und  End-to-End-Tests, da hierbei beliebig viele Klassen im Komponententest zusammengefasst getestet werden können. DeepSampler ist die konsequente Weiterentwicklung gängiger Mocking-Frameworks.

Testautomatisierung: Record and Play

Mit dem DeepSampler lassen sich Softwaresegmente beliebiger Größe isoliert vom Rest des Systems testen, indem alle Schnittstellen nach außen simuliert werden. Hierzu werden die Klassen an den Schnittstellen durch Entwickler markiert. Zur Laufzeit werden die Aufruf- und Rückgabewerte dieser Klassen aufgenommen (Record) und als Testdaten gespeichert. Mithilfe dieser Daten kann man die isolierte Komponente fortan testen. Während eines Testlaufs wird die gesamte Kommunikation der zu testenden Komponente nach außen abgefangen, mit den Testdaten verglichen und eine entsprechende Antwort geliefert beziehungsweise abgespielt (Play).

Komponententest am Beispiel von “Record and Play”

  • Mittels aufgenommener Testdaten lässt sich eine Testautomatisierung aufbauen. Hierbei können dank flexibler Segmentgrößen einzelne Funktionen, Services oder ganze End-to-End-Tests abgebildet werden. Wichtig ist, regelmäßig die Testdaten durch erneute Aufnahmen zu aktualisieren, wenn sich das Verhalten des Programms ändern sollte.
  • Bei der Migration komplexer Legacy-Anwendungen werden gezielt Funktionseinheiten isoliert und aufgenommen. Die aufgezeichneten Testdaten stellen auch nach der Migration sicher, dass sich der neue Code entsprechend der alten Anwendung verhält.

Besonderheiten des DeepSamplers

Während eines Softwaretests werden viele Objekte von Klassen erzeugt, um Operationen auszuführen. Im Vergleich zu ähnlichen Frameworks kann DeepSampler nicht nur ein bestimmtes Objekt einer Klasse manipulieren, sondern manipuliert auch deren Erzeugung. Ergebnis: Alle Objekte einer Klasse, die im Testprozess erzeugt werden, verhalten sich gleich. Das spart viel Zeit. Die Auswirkungen von Anpassungen an einer Klasse werden direkt simuliert – so muss nicht bei jeder im Testprozess generierten Instanz dieselbe Anpassung durchgeführt werden. Metaphorisch gesehen wird also bestimmt, dass jedes Objekt vom Typ „Baum“ gelbes Laub hat, anstatt bei jedem einzelnen Baum die Farbe des Laubs zu definieren.