Tests kennen wir auch. TDD (Test Driven Development) und BDD (Behaviour Driven Development) haben den Umgang mit automatischen Software-Tests bekannt gemacht. Test-First heißt das zugrunde liegende Schlagwort. Es steht für das Motto: Entwickle keinen Produktionscode, zu dem du nicht vorher mindestens einen Test geschrieben hast. In manchen Fällen ist diese Vorgehensweise Straight Forward. Beispiel: Ein unstrukturierter Text muss auf spezielle Weise zerlegt werden. Dafür braucht es eine neue StringUtil-Methode im Produktionscode. Bevor wir diese schreiben, erzeugen wir in der StringUtilTest-Klasse mindestens eine neue Testmethode. Zunächst kompilieren die nicht. Das ändert sich, wenn wir eine leere Methode in der StringUtil-Methode erzeugen. Jetzt sind die Tests ausführbar und natürlich alle rot. Die Arbeit am Produktionscode kann jetzt beginnen. Die Test-First-Vorgehensweise haben wir damit erfolgreich angewandt.
Manchmal ist das Umsetzen dieser Vorgehensweise nicht so Straight Forward. Beispiel: In einer IT-Landschaft geht ein neuer Adress-Service online. In dem von uns betreuten Softwaresystem sollen Service-Adressen abgerufen und verarbeitet werden. Wir müssen eine neue Client-Schnittstelle aufsetzen. Wie sieht hier Test-First aus? Das hängt ein Stück weit von der verwendeten Technologie ab. Außerdem ist zu klären, ob wir unseren Schnittstellentest als Unit-Test aufsetzen oder besser als Integrations- oder Systemtest. Das Testen ist an dieser Stelle sehr lästig, denn als erstes interessiert sich der Entwickler für den sogenannten "technischen Durchstich", d.h. kann ich überhaupt den neuen Service erreichen und sinnvolle Daten abrufen. Häufig ist erst dann der Kopf frei für die Frage: „Und wie kann ich das jetzt automatisch testen?“
Kommentare
Einen Kommentar schreiben