Modultest werden in der Regel vom Entwickler durchgeführt und untersuchen die kleinsten sinnvoll isoliert zu testenden Einheiten wie einzelne Funktionen oder Klassen.
Was wird getestet ?
Modultests betreffen das Testen der kleinsten Software-Einheiten, die sinnvoll isoliert zu testen sind. Dabei kann es sich um einzelne nur von Eingabewerten abhängige Funktionen oder Methoden handeln, um eine einzelne Klasse mit ihren Methoden oder aber – wenn die Funktionalität über mehrere Klassen feingranular verteilt ist – auch um eine Reihe sehr eng interagierender Klassen. Insbesondere bei Methoden, die sich auf den Zustand ihrer Klasse beziehen, ist das isolierte Testen einzelner Methoden nur im Sonderfall für kleine, algorithmisch komplexe Methoden angebracht. Im Kontext moderner Softwareentwicklung basierend auf objektorientierten Sprachen werden auch die Begriffe ‚ Unit-Test‘ und Komponententest benutzt, um die kleinsten sinnvoll testbaren Systemteile zu bezeichnen.
Modultests beschäftigen sich in der Regel hauptsächlich mit funktionalen Eigenschaften und wenden dazu alle Möglichkeiten des Black-Box- wie auch des White-Box-Tests an, da der dazu notwendige Source-Code dem Entwickler vorliegt, der diese Tests häufig im Laufe der Erstellung seines Programms mehrfach und schließlich als Vorbereitung für komplexere Tests durch spezielle Tester selbst durchführt. Liegt neben Schnittstellenbeschreibungen zusätzlich auch semantische Information vor, z.B. durch Zusicherungen über Ein- und Ausgabe-Parameter, werden die Organisation und das Überprüfen der Ergebnisse von Modultests wesentlich vereinfacht.
Wie kann schon früh getestet werden ?
Besonders in sehr frühen Phasen der Entwicklung besteht eine Grundproblematik des isolierten Tests einzelner Module in der Notwendigkeit, zwei Arten von zusätzlichen Objekten zu benötigen, die in der fertiggestellten Implementierung nicht mehr benötigt werden:
-
Einerseits werden sogenannte ‚Treiber‘-Module genutzt, um die interne Funktionalität eines Moduls auch automatisiert aufrufen zu können. Dabei bieten integrierte Testumgebungen heute die Möglichkeit, solche Treiber so zu erzeugen, dass typische Überdeckungsmethoden funktionaler Tests unterstützt werden.
-
Andererseits werden bei nicht vollkommen isoliert arbeitenden Modulen zusätzliche Stellvertreter für evtl. noch nicht vorhandene Module benötigt, die aus dem zu testenden Modul aufgerufene externe Funktionalität simulieren und erst so den vollständigen Durchlauf der zu testenden Funktionen ermöglichen.
Um die nach außen verfügbare Funktionalität der noch nicht vorhandenen Module korrekt einzubinden, sind genaue Schnittstellenbeschreibungen unerlässlich. Die Stellvertreter-Module realisieren dann auf mehr oder weniger triviale Weise die zu ersetzenden Schnittstellen. Hier unterscheidet man‚ Dummies‘, die nur das korrekte Kompilieren erlauben, von sogenannten‚ Stubs‘, die die gewünschte Funktionalität fest kodiert ohne Berücksichtigung des Kontext liefern, von sogenannten‚ Mocks‘, die abhängig von den erwarteten Aufrufparametern und dem aktuellen Aufruf möglichst realistisch überprüfen, ob ein Modul korrekt genutzt wird.
Organisation
Ein weiteres Problem beim Modultest ist methodischer Art und entsteht dadurch, dass die Vorbereitung, Durchführung und Auswertung von Modultests in der Regel von den Entwicklern selbst durchgeführt wird. Diese führen im Vertrauen auf ihre eigenen Programmierleistungen Tests evtl. nur in beschränktem Umfang durch und beschränken sich auf aus ihrer Sicht relevante ‚Problemfälle‘. Dabei werden dann häufig die gleichen ‚Denkfehler‘ bei der Auswahl von Tests gemacht, die schon bei der Programmierung gemacht wurden. Hier sind klare formale Vorgaben zu Umfang und Protokollierung von Tests durch das Projektmanagement unverzichtbar, um schon auf dieser Ebene Qualitätssicherung zu gewährleisten.
Wie alle Stufen des Testeinsatzes ist auch der Modultest typischerweise in ein iteratives Vorgehen zwischen Testen, Feststellen von Fehlverhalten, anschließender Fehlersuche und Behebung des Fehlers durch Programmänderung eingebettet, der nach erfolgter Änderung die Wiederholung der gesamten Tests durch sogenannte Regressionstests notwendig macht, um unerwartete Effekte der eingefügten Änderungen auf Testergebnisse zu erkennen.
Literatur
Sneed, Harry M.; Baumgartner, Manfred; Seidl, Richard: Der Systemtest. 2. Auflage. Spektrum Carl Hanser Verlag : München, 2008.
Tahchiev, P; Leme, F.; Massol, V.; Gregory, G.: JUnit in Action. 2. Auflage. Manning Verlag : Stanford, 2010.
