Will ein Entwickler seine Software mit automatisierten Tests prüfen, muss er komplexe Randbedingungen wiederholbar machen. Dabei helfen ihm Mock-Objekte, die das Verhalten von Produktionscode simulieren, ob es sich nun um ein Netzwerk oder eine Datenbankanbindung handelt.
Software-Entwickler sehen sich immer wieder mit Innovationen konfrontiert, die ihre Arbeit beschleunigen und vereinfachen sollen. Aktuelle Techniken wie agile oder gar extreme Programmierung klingen zwar nach schweißtreibender Arbeit, führen aber einige praktische Techniken ein: Test-getriebene Entwicklung und Unit-Tests.
Unit-Tests setzen auf einer sehr niedrigen Ebene an, testen also möglichst einfache Programmkomponenten einzeln. Idealerweise testen sie genau eine Methode. So bleiben die Tests selbst einfach und frei von Seiteneffekten. Ein Fehler ist meist leicht lokalisierbar.
Allerdings ist diese Ebene nicht immer erreichbar. Oft hängen Klassen voneinander ab oder beeinflussen sich gegenseitig während des Programmablaufs. In solchen Fällen simulieren Mock-Objekte die zeitliche Umgebung (zum Namen siehe den Kasten "Was bedeutet Mock?"). Sie ersetzen während des Testablaufs den Produktionscode des zu testenden Objekts.
Software wird üblicherweise zuerst als Ganzes geplant, danach programmiert und abschließend getestet. Diese Zyklen können sich bei Bedarf wiederholen. Das Test-getriebene Programmieren stellt diese Vorgehensweise auf den Kopf: Das Testen steht am Anfang. Da zu diesem Zeitpunkt aber noch kein passender Programmcode existiert, schlägt der erste Test fehl.
In einem zweiten Schritt behebt der Entwickler diesen Mangel und programmiert den Produktionscode in spe so weit, bis der Test erfolgreich verläuft. Er erstellt also seine Software schrittweise, indem er zuerst eine Erwartung (Expectation) an das künftige Programm formuliert und danach genau diese Erwartung erfüllt. Auf diese Weise entsteht häppchenweise eine Applikation, die der geforderten Aufgabe entspricht.
Soweit die Theorie. Natürlich sind derartige Tests noch keine Garantie für korrekte Programme. Aber durch das Schreiben von Tests setzt sich der Programmierer intensiver mit seinem Code auseinander und kommt daher dem Ziel zumindest näher. Fast noch wichtiger: Er kann es bereits während der Entwicklung erreichen. Es ist nicht mehr nötig, Teile der Software wie Bananen beim Kunden reifen zu lassen.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
