Mock-Objekte für Unit-Tests mit C++
Aufmerksamer Beobachter
von Ewald Arnold
Erschienen im Linux-Magazin
2005/04
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.
Komponenten testen
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.
Entwickeln mit Tests
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.
| Whitepaper |
|
Daten Migration - Eine Publikation von Bloor Research
Datenmigrationsprojekte überschreiten häufig das Budget, neigen zu Verzögerung und werden unter Umständen komplett abgebrochen. Bloor Research ist eines der weltweit führenden IT-Forschungs-, Analyse- und Beratungsunternehmen und wird in dem vorliegenden White Paper die wichtigsten Aspekte dieser Problematik näher beleuchten. Ferner werden praktische Empfehlungen für erfolgreiche Migrationsprojekte gegeben, die Sie auf Ihr nächstes Projekt übertragen können.
Download PDF (Registrierung erforderlich)
|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele
Über die letzten Jahre hinweg haben sich Open Source Lösungen als fester Bestandteil des gesamten Datenintegrationsmarktes etabliert. Viele Unternehmen haben bereits das Open Source Modell für Ihre Datenintegrationsprojekte aufgegriffen. Das vorliegende White Paper illustriert anhand ausgewählter Fallstudien und Anwendungsbeispiele die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|