Softwareentwicklung: Wenn testgetriebene Entwicklung einfach nicht gut genug ist

Es ist fast unmöglich, bei Tests alle möglichen Bugs auszuschließen. TDD kann es jedenfalls nicht - mit mutationsgetriebenen Tests stehen die Chancen besser.

Artikel von Rajiv Prabhakar veröffentlicht am
Scheitern gehört zum Konzept bei TDD.
Scheitern gehört zum Konzept bei TDD. (Bild: Pixabay / Montage: Golem.de)

Dieser Text ist eine Übersetzung. Das Original ist hier zu finden.

Inhalt:
  1. Softwareentwicklung: Wenn testgetriebene Entwicklung einfach nicht gut genug ist
  2. Ein TDD-Beispiel
  3. Und jetzt fügen wir alles zusammen

Als jemand, der gerne über Software-Handwerkskunst und Best Practices spricht, ist testgetriebene Entwicklung (Test Driven Development, TDD) für mich ein wunder Punkt. Zunächst einmal: Ich mag es sehr, dass die Betonung bei TDD auf "Testen" liegt. Zu viele Software-Projekte vernachlässigen das Testen - und die Ergebnisse sprechen für sich, wenn Änderungen viele Jahre später exponentiell länger brauchen, um implementiert zu werden, und Programmierer irgendwann Angst bekommen, überhaupt etwas anzufassen.

Trotzdem muss ich sagen, dass ich noch nie ein großer Fan von TDD war. Einerseits ist es zu strikt. Das Beharren darauf, zuerst Tests zu schreiben, steht der explorativen Arbeit oft im Weg - Arbeit, die nötig ist, bevor man herausfinden kann, welche die richtigen Schnittstellen, Methoden und OO-Strukturen sind.

Andererseits ist TDD zu nachsichtig. Viele Praktiker gehen davon aus, dass, weil sie TDD praktizieren, ihre Testsuite grundsolide ist. Ich habe aber schon zu viele Tests gesehen, die mit TDD geschrieben wurden und trotzdem große Abdeckungslücken aufwiesen; Abdeckungslücken, die zu Produktionsfehlern führen können und werden, jetzt oder in der Zukunft. Was die Testmethodik angeht, sollte das Schließen der Abdeckungslücken oberste Priorität sein - und alle anderen Modeerscheinungen und Empfehlungen in den Hintergrund stellen.

Daher wird meine bevorzugte Testphilosophie am besten durch das mutationsgetriebene Testen (Mutation Driven Testing) veranschaulicht, das dieser Abfolge von Schritten folgt:

1. Erreichen Sie einen Zustand, in dem Sie sowohl Code als auch erfolgreich durchlaufende Tests haben.
1.1 Ob Sie zuerst den Code oder zuerst den Test schreiben sollten, sollte an anderer Stelle diskutiert werden. Um an diesen Punkt zu kommen, können Sie gern auch TDD nutzen.

2. Gehen Sie Ihren neu hinzugefügten/geänderten Code Zeile für Zeile durch und setzen Sie manuell einen einzelnen Fehler.
2.1 Bei der Frage, welcher Fehler sich eignet, ziehen Sie vor allem Fehler aus Nachlässigkeit, Faulheit, Unerfahrenheit und Inkompetenz in Betracht, nicht aber böswillige Fehler. Tests zu entwerfen, die böswillige Bugs finden, ist exponentiell schwieriger und nicht sehr realistisch.

3. Überprüfen Sie, ob ein Test jetzt fehlschlägt.

4. Wenn ein Test nicht fehlschlägt, überprüfen Sie, welche Abdeckungslücken Sie in Ihren Tests haben, und beheben Sie diese, indem Sie neue Tests hinzufügen oder Ihre vorhandenen Tests aktualisieren.
4.1 Je besser Sie beim Schreiben von Tests werden, desto seltener sollte das vorkommen.

5. Machen Sie Ihren Fehler rückgängig und überprüfen Sie, ob Ihre Tests jetzt funktionieren.

6. Gehen Sie zurück zu Schritt 2 und wiederholen Sie den Vorgang, bis Sie jeden erdenklichen Fehler eingefügt haben oder Ihnen die Zeit ausgeht.
6.1 Sie werden irgendwann ein Gespür dafür entwickeln, welche Bugs am wahrscheinlichsten an Ihrer Testsuite vorbeikommen. Das wird diesen Prozess stark beschleunigen und Sie werden lernen, umfassendere Tests zu schreiben.

Die Philosophie: Jeden Fehler manuell testen

Die Philosophie hinter mutationsgetriebenen Tests ist einfach. Denn die einzige Möglichkeit, die Zuverlässigkeit Ihrer Testsuite zu beurteilen, besteht darin, zu sehen, ob sie versagt, wenn ein Fehler vorhanden ist. Also konstruieren Sie diesen Fehler einfach selbst.

Anschließend verwenden Sie das Testergebnis, um herauszufinden, wo Ihre Abdeckungslücken sind, und schließen sie. Und zwar nicht nur, um Ihren spezifischen Fehler abzufangen, sondern auch jede andere ähnliche Kategorie von Fehlern. Indem Sie das tun, können Sie die blinden Flecken in Ihrer Testsuite identifizieren und Ihre Testabdeckung entsprechend verbessern.

Es gibt übrigens Werkzeuge, die versuchen, diese Form des mutationsgetriebenen Testens zu automatisieren. Ich freue mich auf den Tag, an dem sie zum Mainstream werden und genauso umfassend sein werden wie die manuellen Mutationen. Für den Moment konzentriert sich dieser Artikel aber auf Letztere.

Sicher schreien jetzt ungefähr eine Million TDD-Befürworter laut auf.

"Aber Sie müssen doch gar keine Mutationstests machen, wenn Sie TDD gemacht haben! Wenn Ihr TDD gut ist, wird jede einzelne Funktionalität einen dedizierten Test haben, also gibt es keine Abdeckungslücken!"

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed
Ein TDD-Beispiel 
  1. 1
  2. 2
  3. 3
  4.  


Robert.Mas 21. Apr 2021

Du meinst so wie hier im Artikel: "Es gibt übrigens Werkzeuge(Link: https://pitest.org...

kayozz 21. Apr 2021

+1 Allein dadurch, dass ich von außen einen Test schreibe, und danach die...

Steffo 20. Apr 2021

Sagt er doch gar nicht: "1. Erreichen Sie einen Zustand, in dem Sie sowohl Code als auch...

Steffo 20. Apr 2021

Alles, was du hier ansprichst, behandelt doch der Artikel. Dadurch lassen sich natürlich...



Aktuell auf der Startseite von Golem.de
Grüner Wasserstoff
Neues Verfahren erzeugt Wasserstoff aus Salzwasser

Wo es Sonne gibt, um Wasserstoff zu erzeugen, fehlt es oft an Süßwasser. Ein neu entwickelter Elektrolyseur kann das im Überfluss vorhandene Meerwasser verarbeiten.

Grüner Wasserstoff: Neues Verfahren erzeugt Wasserstoff aus Salzwasser
Artikel
  1. Ukrainekrieg: Palantir für die militärische Zielauswahl verantwortlich
    Ukrainekrieg
    Palantir für die militärische Zielauswahl verantwortlich

    Das US-Unternehmen Palantir ist mit Software am Kriegsgeschehen in der Ukraine beteiligt. Auch die hiesige Polizei setzt Software des Unternehmens ein.

  2. Streaming: Netflix streicht Funktion aus drei Abomodellen
    Streaming
    Netflix streicht Funktion aus drei Abomodellen

    Künftig gibt es 3D-Raumklang alias Spatial Audio nur noch im teuersten Netflix-Abo. Wirbel entfacht eine Filmveröffentlichung in Japan.

  3. Software: Wie Entwickler Fehler aufspüren - oder gleich vermeiden
    Software
    Wie Entwickler Fehler aufspüren - oder gleich vermeiden

    Es gibt zahlreiche Arten von Softwarefehlern. Wir erklären, welche Testverfahren sie am zuverlässigsten finden und welche Methoden es gibt, um ihnen vorzubeugen.
    Von Michael Bröde

Du willst dich mit Golem.de beruflich verändern oder weiterbilden?
Zum Stellenmarkt
Zur Akademie
Zum Coaching
  • Schnäppchen, Rabatte und Top-Angebote
    Die besten Deals des Tages
    Daily Deals • Samsung G5 Curved 27" WQHD 260,53€ • Graka-Preisrutsch bei Mindfactory • Samsung Galaxy S23 jetzt vorbestellbar • Philips Hue 3x E27 + Hue Bridge -57% • PCGH Cyber Week • Dead Space PS5 -16% • PNY RTX 4080 1.269€ • Bis 77% Rabatt auf Fernseher • Roccat Kone Pro -56% [Werbung]
    •  /