Test Driven Development – Programmieren auf den Kopf gestellt

Eile mit Weile

Es ist nichts Neues. Zeit und Qualität hängen stark miteinander zusammen. Je mehr Zeit man für ein Projekt zur Verfügung hat, desto höher kann der Qualitätsstandard sein. Nur ist die Zeit meistens aus Kostengründen knapp bemessen. Wie soll man es also trotzdem schaffen, in kurzer Zeit eine hochwertige Softwarelösung zu implementieren? Eine Möglichkeit ist die testgeleitete Softwareentwicklung oder „Test Driven Development“ (TDD). Dabei handelt es sich um eine Designstrategie für Softwareentwicklung, bei der sogenannte Unit-Tests zeitgleich mit dem Produktionscode geschrieben werden.

Hab ich schon mal gehört

Viele haben davon gehört, wenige setzen es um. „Es ist teuer!“, „Das lohnt sich nicht für so ein kleines Projekt!“, „Wir haben doch keine Zeit!“, „Hier muss alles schnell gehen“. Man könnte hier noch viele weitere Ausreden aufzählen, aber es würde nichts daran ändern, dass es eben nur Ausreden sind.

Unsere Erfahrung zeigt, dass man mit TDD in kurzer Zeit und mit einem hohen Standard Softwarelösungen oder einzelne Funktionalitäten implementieren kann.

Glauben Sie nicht?

Na dann lassen sie sich mal überraschen. Man muss es einfach nur richtig machen. Dafür benötigt man aber ein bisschen Erfahrung. Darum lassen wir Sie an unserer teilhaben. Hier haben wir für Sie die wichtigsten Faktoren für erfolgreiche TDD zusammengestellt.

Die Perfektion der Imperfektion

Als erstes muss man sich von der Erwartung verabschieden, dass man einfach eine Testabdeckung von 100 Prozent vorschreiben kann. Auch wenn es vielleicht wünschenswert ist, erreicht man auch mit dem konsequentesten Einsatz von TDD wohl eher nur die 80 Prozentmarke. Natürlich variiert dies stark mit den einzelnen Aufgaben. Seien Sie aber nicht traurig darüber, sondern freuen sich des Lebens. Denn die Erfahrung zeigt, dass bei einer vorgegeben hohen Abdeckungsrate, viele Tests sowieso nur für die Erreichung dieser geschrieben werden. So verlieren die Tests und schlussendlich das Gesamtsystem an Qualität und werden zum Wartungsproblem.

Die drei goldenen Regeln

Befolgen sie diese drei simplen Regeln von R.C. Martin (Clean Code):

1. Man darf keinen Produktiv-Code schreiben, bevor man nicht einen fehlgeschlagenen Test geschrieben hat
2. Man darf nicht mehr Code für einen Unit-Test schreiben, als für das Fehlschlagen des Tests notwendig ist. Man beachte: Nicht kompilierbar bedeute fehlgeschlagen
3. Man darf nicht mehr Produktionscode schreiben, als notwendig ist, um einen fehlgeschlagenen Test zu bestehen

Schlampig war gestern

Sind wir mal ehrlich, eigentlich gibt es keinen Fall, wo ein schlampiges Ticketing erlaubt ist. Für den Erfolg von TDD muss dieses wirklich gewissenhaft geführt werden. Das heisst, der Ticketinhalt muss genau spezifiziert und der Arbeitsaufwand vernünftig eingeschätzt werden. Damit man auch so richtig TDD praktizieren kann, muss es sich beim umzusetzenden Task um eine „Business Logik“-Aufgabe handeln und z.B. nicht nur eine Frontend-Anpassung oder Systemkonfiguration. Zu Beginn werden die Teammitglieder sicher etwas über die neuen Ticketing-Richtlinien stöhnen, sobald sich aber die Regeln in den Köpfen der Leute festgesetzt haben, wird es wieder ruhiger im Büro.

Nur für Clean Code-Anhänger

Selbstverständlich sollte jeder Code, der geschrieben wird, ob mit oder ohne TDD den Clean-Code-Prinzipien entsprechen. Also halten Sie sich auch bei TDD dran.

Kosten? Investition!

Das altbekannte „Aber das treibt doch die Projektkosten in die Höhe!“ kommt bei TDD so sicher, wie das Amen in der Kirche. Wenn der Kunde ein Projekt in Auftrag gibt, geht er davon aus, dass die Softwarelösung qualitativ hochwertig und einfach zu warten sein wird. Und da hat er ja auch recht damit. Die Kunden profitieren zwar von TDD aber die wahren Gewinner sind die IT-Dienstleister, die es in den Organisationen integrieren. Der Aufwand für die Ausbildung der Entwickler zahlt ich schnell durch weniger Wartung, zufriedenere Kunden und produktivere Mitarbeiter aus. Denn bei TDD geht es nicht nur darum eine Programmiertechnik einzuführen. Es geht darum eine gesamtheitliche Unternehmensstrategie zu unterstützen, die darauf abzielt, dem Kunden kontinuierlich höchste Software-Qualität zu liefern. Darum ist es eine Investition des IT-Dienstleisters in die Qualität seines eigenen Produktes.