Test-Driven Development (TDD): Plage oder Allheilmittel?

Kommentar verfassen / Allgemein / Von

Man hat es schon mal irgendwo gehört: „Für jede neue Zeile Produktionscode muss ein (failing) Test existieren“ oder eine Variante davon. Sinngemäß soll die Aussage von Kent Beck stammen als er in den 90ern über Extreme Programming (XP) geschrieben hat. Aber was hat es uns seitdem gebracht?

Die Idee ist simpel: Tests zuerst schreiben für die neue Funktionalität, danach den Code schreiben, um die Tests grün leuchten zu lassen. Auf Basis dieser Tests kann dann in Ruhe refactored werden (auch ein XP-Prinzip). Warum also nicht?

Im Laufe der Zeit habe ich in verschiedene Software Entwicklungsprojekte beobachtet, dass Tests entweder:
a) Gemieden werden (mit verschiedenen Begründungen)
b) Halbherzig umgesetzt werden (in der Regel durch „Abwälzung“ der unliebsamen Aufgabe auf einer Testabteilung)
c) Mit gesetzten hohen Coverage-Ziele als KPIs pauschal in den Kampf gehen.

Kent Beck hat seine Aussage übrigens in ein sehr empfehlenswerten Talk (s. Link unten) diese Aussage relativiert, da wie er sagt die Rechnung nicht ausgeht wenn auf jede Zeile Code jeweils 4 Zeilen Testcode erstellt. Dann ist es natürlich unvermeidbar, dass bei jeder funktionalen Umschreibung (nicht Refactoring) immer ein vielfaches an Arbeit anfällt.

Was also tun? Hier einige Möglichkeiten:

  • Nur „critical Code“ mit hoher Testabdeckung belegen (die Frage, welcher Code critical ist, lässt sich leider nicht pauschal beantworten)
  • Behavior Driven Development (BDD) einsetzen (s. auch Links am Ende des Posts) – Eine Technik, die fachliche Tests in einer high-level Sprache ermöglicht und somit weniger häufig der Aktualisierung bedarf.
  • Test-Ebene variieren. Unit Tests sind zwar „billig“, können aber nur kleine Einheiten technisch testen. UI-Tests (automatisierte End-to-end-Tests) sind aufwändiger, müssen aber auch nicht oft verändert werden. Eine Kombination der Ebenen ist häufig sinnvoll und bringt am Meisten wenn bewusst geplant und verschriftlicht.

Was weniger sinnvoll ist:

  • Feste Coverage Vorgaben z.B. mindestens 90%. Man kann ja „schlechte Tests“ schreiben die viel abdecken, ohne dass man sonst einen Mehrwert daraus erzeugt.
  • Eine einzige Art von Tests (z.B. nur Unit Tests oder nur Integration Tests)

Künftig stellt sich die Frage, inwiefern GPT und ähnliche KI-Modelle bei der Testerstellung unterstützen könnten. Dies ist aber ein Thema für einen anderen Beitrag.

Links

Kommentar verfassen