„Modultest“ – Versionsunterschied

Ein Modultest (auch von englisch unit test als Unittest oder als Komponententest bezeichnet) ist ein Softwaretest, mit dem einzelne, abgrenzbare Teile von Computerprogrammen (z. B. ausgewählte Codeabschnitte, Module, Unterprogramme, Units oder Klassen) überprüft werden. Testziel dieser häufig durch den Softwareentwickler selbst durchgeführten Softwaretests ist, deren technische Lauffähigkeit und die Korrektheit ihrer fachlichen (Teil-)Ergebnisse nachzuweisen.

Der Ausdruck Modultest wird auch als eine frühe Teststufe verstanden, in der die inneren, detailliertesten Komponenten der Software getestet werden. Siehe dazu auch die Grafik Stufen des V-Modells im Vorgehensmodell (nach Barry Boehm). Gemäß Software Validation & Verification Plan sind Modultests nur für Module mit geringer Kritikalität (die bei Fehlern den Benutzern nur geringe Unannehmlichkeiten bereiten) nicht notwendig.

Einordnung im Testprozess

→ Hauptartikel: Softwaretest

Da Algorithmen auf Unitebene meist nur eine begrenzte Komplexität aufweisen und über klar definierte Schnittstellen aktiviert werden, können sie mit relativ wenigen Testfällen weitgehend vollständig getestet werden. Dies gilt als Voraussetzung für die anschließende Teststufe Integrationstest, um dort die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausrichten zu können; die modulspezifischen Detailkonstellationen lassen sich damit dort auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle drastisch reduziert.

Zum Vergleich: Ein Gerät wird erst dann als Ganzes getestet, wenn die Funktionsfähigkeit seiner Einzelteile als gesichert gilt.

Verfahren zur Testfalldefinition

Modultests zählen zu den White-Box-Tests. Das heißt, dass bei der Definition der Testfälle der zu testende Quellcode bekannt ist. Die Spezifikation der Software wird lediglich für die Bestimmung der Soll-Ergebnisse benutzt. Prinzipiell müssen alle Quellcode-Teile mindestens einmal ausgeführt werden. Anweisungsüberdeckung, Zweigüberdeckung oder Pfadüberdeckung können dabei helfen festzustellen, welche Testfälle hierzu in der Theorie mindestens erforderlich sind (siehe dazu Kontrollflussorientierte Testverfahren). In der Praxis versucht man in aller Regel, das gesetzte Überdeckungsziel mit möglichst wenigen Testfällen zu erreichen, da alle Modultests auch laufend gepflegt werden müssen.

Verfahren zum Erstellen von Modultests

Üblicherweise orientieren sich alle Modultests an einem einheitlichen Grundaufbau. Dabei wird zunächst (1) ein Ausgangszustand initialisiert, hierauf (2) die zu testende Operation ausgeführt und zuletzt (3) das Ist-Ergebnis mit einem aus der Spezifikation abgeleiteten Sollwert verglichen. Für diese Vergleiche stellen die Test-Frameworks assert-Methoden (deutsch etwa: feststellen, versichern) zur Verfügung.

Eigenschaften von Modultests

Isolierung von Testobjekten

Modultests testen ein Modul isoliert, d. h. weitgehend ohne Interaktion mit anderen Modulen. Deshalb müssen oder können bei Modultests andere Module beziehungsweise externe Komponenten wie etwa eine Datenbank, Dateien, Backendsysteme oder Unterprogramme durch Hilfsobjekte simuliert werden, soweit das zu testende Modul (Prüfling oder Testobjekt) dies erfordert.

Dazu einsetzbare Hilfsobjekte lassen sich im Wesentlichen danach unterscheiden,

• ob sie ein aufzurufendes Modul ersetzen (Prüfling ist das aufrufende Modul; das Ersatzobjekt wird ‚Stub‘ genannt),
• ob sie den Aufruf (die Umgebung) eines zu testenden Moduls/Unterprogramms ersetzen (Prüfling ist die Unterroutine, die den Aufruf simulierende Routine wird ‚Driver‘ genannt).

Wie vollständig die Hilfsroutine das Verhalten des Originals abbildet, etwa bei Plausibilitätsprüfungen oder bei der Rückgabe von Antwortcodes, ist durch entsprechendes Testfalldesign zu berücksichtigen. Besonders in objektorientierten Programmiersprachen lassen sich diesbezüglich weitere, detailliertere Kategorien von Hilfsobjekten unterscheiden, siehe Mock-Objekt.

Derartige Hilfsobjekte werden z. B. als Stellvertreter implementiert und mittels Inversion of Control bereitgestellt. Ein Modul kann so meist einfacher getestet werden, als wenn alle Module bereits integriert sind, da in diesem Fall die Abhängigkeit der Einzelmodule mit in Betracht gezogen und im Testhandling berücksichtigt werden müsste. Auch sind derart isolierte Modultests schon möglich, wenn andere, eigentlich benötigte Komponenten für den Test noch nicht verfügbar sind.

Vollständige Tests mit allen Komponenten in ihrer Originalversion sind Gegenstand der später stattfindenden Integrations- und Systemtests – wobei ggf. im Modultest nicht erkannte Fehler (z. B. wegen identischer Falschannahmen für das Testobjekt und die Hilfsroutine) entdeckt werden sollten.

Test des Vertrages und nicht der Algorithmen

Modultests testen gemäß dem Design-by-contract-Prinzip möglichst nicht die Interna einer Methode, sondern nur ihre externen Auswirkungen (Rückgabewerte, Ausgaben, Zustandsänderungen, Zusicherungen). Werden die internen Details der Methode geprüft (dies wird als White-Box-Testing bezeichnet), könnte der Test fehlschlagen, obwohl sich die externen Auswirkungen nicht geändert haben. Daher wird in der Regel das sogenannte Black-Box-Testing empfohlen, bei dem man sich auf das Prüfen der externen Auswirkungen beschränkt.

Automatisierte Modultests

Mit der Verbreitung von agilen Softwareentwicklungsmethoden und insbesondere testgetriebener Entwicklung ist es üblich geworden, Modultests möglichst automatisiert auszuführen. Dazu werden üblicherweise mit Hilfe von Test Frameworks wie beispielsweise JUnit Testprogramme geschrieben. Über die Test Frameworks werden die einzelnen Testklassen aufgerufen und deren Komponententests ausgeführt. Die meisten Test Frameworks geben eine grafische Zusammenfassung der Testergebnisse aus.

Automatisierte Modultests haben den Vorteil, dass sie einfach und kostengünstig ausgeführt und dass neue Programmfehler schnell gefunden werden können.

Vorteile

• Mittels automatisierter Unittests können im Schnitt 30 % der Fehler erkannt werden. Bei der Verwendung von testgetriebener Entwicklung können im Schnitt 45 % und im besten Fall 85 % der Fehler vermieden werden.
• Fehler werden durch Modultests bereits während der Entwicklung erkannt. Die durch Unittests vermiedenen Fehlerkosten sind daher gemäß der Rule of Ten um ein vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen.
• Im Falle eines Fehlers kann dieser sehr viel genauer eingegrenzt und damit schneller gefunden und behoben werden.
• Die Tests erfüllen den Zweck einer lebenden Dokumentation. In Kombination mit einer sinnvollen Benennung der Objekte (Clean Code) können zusätzliche Dokumentationsmaßnahmen entfallen.
• Da einzelne Module nur wenige mögliche Codeausführungspfade besitzen, müssen viel weniger mögliche kombinatorische Ausführungspfade berücksichtigt werden, als bei anderen Testarten. Übergeordnete Tests können sich stichprobenartig auf die wichtigsten Ausführungspfade konzentrieren und damit deutlich reduziert werden.
• Da nur einzelne Module getestet werden, können Modultests, oft um mehrere Größenordnungen, schneller und damit öfter (bzw. kontinuierlich) ausgeführt werden als andere Testarten.
• Wenn Fehler mit einem Test abgesichert werden, wird verhindert, dass dieser Fehler erneut auftritt.
• Durch die Fehlerreduktion ergeben sich Geschwindigkeitsvorteile in der Entwicklung in mittleren bis großen Softwareprojekten.
• Da Abhängigkeiten zwingend vermieden werden müssen, um einen Modultest zu ermöglichen, bleibt der Code verhältnismäßig schnell änderbar. Hierdurch kann schneller auf wechselnde Anforderungen reagiert werden.
• Da automatisch ausgeführte Tests um mehrere Größenordnungen schneller sind als manuelle Tests, reduziert sich der Zeitaufwand für das Testen deutlich. Hierdurch können Entwicklungsstufen schneller durchlaufen und die Release-Zyklen verkürzt werden.

Nachteile

• Bei Implementierung neuer Funktionalität muss nicht nur die Funktion implementiert, sondern es müssen auch die dazugehörenden Tests vorbereitet/definiert werden. Es ergibt sich somit ein oft mehrfacher Implementierungsaufwand.
• Bei Änderungen müssen nicht nur die geänderten Funktionalitäten, sondern auch die dazugehörenden Tests angepasst werden. Insbesondere bei der Entwicklung von Prototypen, bei der sich die Codebasis schnell verändert, ist das Testen daher oft hinderlich.
• Da die Funktionalität von den Tests verwendet wird, ist in IDEs schwerer ersichtlich, ob eine Funktionalität nicht mehr anderweitig verwendet wird und daher entfernt werden kann.
• Weisen die Tests untereinander Abhängigkeiten auf (z. B. durch gemeinsame Testdaten), so können einzelne Änderungen an der Codebasis eine Vielzahl von Tests beeinflussen, was den Änderungsaufwand mit der Größe der Codebasis exponentiell erhöht.

Grenzen von Modultests

Modultests können (wie jeder Test) die Fehlerfreiheit des getesteten Moduls nicht garantieren oder nachweisen, sondern lediglich unterstützen. Die Grenzen von Modultests liegen notwendigerweise darin, dass nur solche Fehler gefunden werden können, zu deren Entdeckung die verwendeten Tests geeignet sind. Eine Softwarekomponente, die „grün“ testet, ist also nicht unbedingt fehlerfrei.

Das Merkmal von Code, „grün“ zu testen, und durchaus auch der Wunsch nach diesem Ergebnis, könnte dazu führen, dass tatsächlich (unbewusst) nur so viel getestet wird, bis alle Tests „grün“ sind. Module, die keine fehlschlagenden Modultests haben, als fehlerfrei zu behandeln, ist ein Fehlschluss in der Praxis testgetriebener Entwicklung.

Um eine ausreichende Testabdeckung zu erzielen, lohnt es sich u. U., vor dem Erstellen der Testfälle Refactoring-Maßnahmen anzuwenden. Dies erst nach abgeschlossenen Modultests (für den alten Code) zu tun, würde (wie jede Änderung im Code) neue Fehlerrisiken bergen und deshalb wiederholtes Testen erforderlich machen.

Wenn der Autor von Modultests mit dem Autor der Module identisch ist, können Denkfehler in der Implementierung auch im Test erscheinen und nicht aufgedeckt werden. Wenn es sich um dieselbe Person handelt, wird dies auch nicht dadurch ausgeschlossen, dass die Tests zuerst entwickelt werden, da sowohl die beabsichtigte Funktionsweise des Codes als auch seine zukünftige Gestalt bereits im Denken des Testautors und späteren Codeautors präsent sein können. Dies kann im Extreme Programming durch „Test Ping-Pong“ abgefangen werden, bei der sich Entwickler bei der Implementierung der Funktionalität und der Tests abwechseln.

Bei der Entwicklung von Modultests können Testfälle entstehen, die der Zielsetzung und dem Charakter von Modultests nicht oder nur zum Teil entsprechen. Wie bei der Programmierung existieren daher auch für die Entwicklung von Modultests Anti-Pattern, die möglichst vermieden werden sollten.

Siehe auch

• Liste von Modultest-Software
• Testgetriebene Entwicklung
• Verhaltensgetriebene Softwareentwicklung

Literatur

• Paul Hamill: Unit Test Frameworks. (A Language Independent Overview). O’Reilly Media, Beijing u. a. 2004, ISBN 0-596-00689-6 (englisch). 
• Gerard Meszaros: xUnit Test Patterns. Refactoring Test Code. Addison-Wesley, Upper Saddle River NJ u. a. 2007, ISBN 978-0-13-149505-0 (englisch). 
• Andreas Spillner, Tilo Linz: Basiswissen Softwaretest. Aus- und Weiterbildung zum Certified Tester. Foundation Level nach ISTQB-Standard. 4., überarbeitete und aktualisierte Auflage. dpunkt-Verlag, Heidelberg 2010, ISBN 978-3-89864-642-0. 

Weblinks

• Linkkatalog zum Thema Unit-Testing bei odp.org (ehemals DMOZ) (englisch)
• Einführung in die Prinzipien von Unit-Tests
• Entwicklung von Modul Tests mit Beispielen, Autor Markus Lenger, in: Informatik Aktuell
• Artikel zum Thema Komponententests unter Java (englisch)