Eigenschaften

Alternativen Bezeichnungen

Modultests werden abhängig von der Art der Implementierung auch Komponententests, Unittests oder Klassentests genannt.

Testobjekte

Die zu testenden Objekte sind (bei OO Entwicklung) die einzelnen Klassen und Methoden.

Tester

Die Test werden durch den Entwickler durchgeführt.

Testziel

Die Modultests konzentrieren sich hauptsächlich auf die korrekte Implementierung von (Teil-) Funktionalität und Robustheit, beispielsweise gegen Fehleingaben oder falsche Übergabeparameter.

Testwerkzeuge

JUnit, wie der Name schon andeutet, wurde speziell für das Testen von Programmeinheiten oder -komponenten konzipiert. Damit lassen sich die Tests nicht nur durchführen, sondern auch verwalten und automatisieren.

Mit Clover kann schließlich die Vollständigkeit des Testens (im Sinne eine Code-Coverage) nachgewiesen werden.

Vorgehen

Testen der Stabilität

Um Funktionalität und Robustheit von Komponenten/Klassen/Methoden zu überprüfen sollten getestet werden:

Verschiedene Kombinationen von Übergabeparametern durch Bildung von Äquivalenzklassen
Falsche Datentypen, null-Werte, zu große oder zu lange Werte
Verschiedene Encodings: z.B. Unicode-Characters

Testen der Korrektheit

Um Berechnungen bzw. die Korrektheit von Rückgabewerten zu überprüfen, sollten nicht nur verschiedene Kombinationen an Übergabeparametern, sondern auch verschiedene Durchlaufpfade durch das Programm getestet werden. Abhängig von der Testplanung sollten die dort definierten Werte eines Code-Coverage erreicht werden. Da auch hier die Anzahl der Möglichkeiten an Durchläufen durch ein Programm sehr hoch (s.u.) und damit nicht mehr vollständig testbar werden kann, sollten zwei Dinge getan werden:

Das Programm/Modul/Methode sollte so umgeschrieben werden, dass die zyklomatische Komplexität kleiner 8 bleibt
Die Forderung nach 100%er Abdeckung (Coverage), sollte sich nur auf Anweisungs- und Zweigabdeckung, jedoch nicht auf Pfadabdeckung beziehen

Das nachfolgende Beispiel zeigt einen Programmgraphen mit 5 möglichen Programmdurchläufen, falls die äußere Schleife nicht durchlaufen wird. Falls die Schleife 0-20 Mal durchlaufen werden kann, existieren

5 + 5^1 + 5^2 + ... + 5^20

Möglichkeiten, für die man bei 5µs pro Test 89 Jahre brauchen würde.

Tritt Modultesten in einer Methode das Problem auf, dass sich Zwischenwerte in einem Programmablauf nicht testen lassen, so ist das ein Hinweis auf falsches Design und legt ein Refactoring nahe, beispielsweise durch Auftrennung dieser Methode in mehrere.

TODO Beispielcode

Testen der Fehlerbehandlung

Das Überprüfen der Fehlerbehandlung wird beim Testen sehr oft vernachlässigt. Auch hier geben die Abdeckungsgrade (Coverage) Auskunft darüber, wo das Testen noch unvollständig ist.

Testen von Zuständen und Zustandsübergängen

Besonders bei Zustandsautomaten spielt die Historie/Reihenfolge des Testens eine Rolle. Ein populäre Beispiel ist der Stack, bei dem es einen Unterschied darstellt, ob zuerst Elemente auf einen leeren Stack gelegt und dann von diesem entfernt werden, oder ob versucht wird, zuerst Elemente vom leeren Stack zu entfernen (was zu einem Fehler führen muss).

Die Tests sollten also alle Zustände und alle erlaubten und unerlaubten Übergänge testen. Letztere führen zu einem Test der Fehlerbehandlung.

Statische Tests

Die Gedanke des eXtreme Programmings aufgreifend, sollte ein Modultest unbedingt durch einen statischen Test ergänzt werden!