Testen: Unittest, doctest, py.test, etc. -- Komponenten- und Funktionstests

Autor

Stefan Schwarzer

Außer mir haben noch weitere Teilnehmer tolle Infos beigetragen, an die ich mich aber nicht mehr erinnere. Es wäre schön, wenn ihr diese Informationen hier zumindest kurz anreißen könntet.

Komponenten- und Funktionstests

Komponententests testen Software-Komponenten üblicherweise auf API-Ebene. Jeder Programmierer bzw. jede Programmiererin sollte seine/ihre Software-Komponenten automatisiert testen. Im Gegensatz zu Komponententests prüfen Funktionstests das erwartete Verhalten der Software aus Anwendersicht.

Test-Frameworks für Python

Python liefert zwei Module für Komponententests mit. Das Modul unittest bietet eine an JUnit angelehnte Servlet-Schnittstelle: TestCase-Klassen leiten von unittest.TestCase ab. Innerhalb dieser Klassen stehen Methoden, die wiederum Methoden wie assertEqual aufrufen, die letzlich die erwarteten Bedingungen prüfen.

Dagegen schreibt man bei Verwendung von doctest Python-Code so, wie man ihn auch im Interpreter eingeben würde, einschließlich der erwarteten Ausgaben.

Das unittest-Framework unterstützt so genannte Fixtures, die vor und nach jedem Testfall definierte Anfangs- und Endzustände sicherstellen. Bei doctest ist das nicht möglich, was Letzteres einige Flexibilität kostet.

Neben unittest und doctest gibt noch weitere Test-Frameworks für Komponententests, die nicht in der Python-Distribution enthalten sind. Die bekanntesten Frameworks dieser Art sind wohl py.test und nosetest.

Die Unterschiede dieser Test-Frameworks bestehen nicht nur darin, wie Tests auf Bestehen geprüft werden, sondern auch wie Tests in einem Verzeichnisbaum gefunden werden ("Testrunner").

Für Funktionstests gibt es die Bibliothek Texttest, bei denen einer der Teilnehmer jedoch eine verbesserungswürdige Dokumentation beklagte. In die Kategorie "Funktionstest" gehört auch Software wie Selenium zum "Fernsteuern" eines Web-Clients.

Mock-Objekte

Manche Funktionen im Code lassen sich nur schwer testen, zum Beispiel der Ausfall einer Netzwerkverbindung. Hier bedient man sich so genannter Mock-Objekte. Grundsätzlich ist zu beachten, dass dieser Mock-Code nicht so kompliziert ist, dass er selbst Tests benötigt. Vor allem sollte man es im Interesse der Wartbarkeit vermeiden, komplexere Mock-Objekte oder -Daten zu schreiben, die von mehreren Testfällen benutzt werden.