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.

Stellenmarkt
  1. SPS-Programmierer / Softwareentwickler (m/w/d)
    D. Kremer Consulting, Bielefeld
  2. Senior Architect Microsoft Azure (m/w/d)
    operational services GmbH & Co. KG, Frankfurt am Main, Berlin, Dresden, München, Wolfsburg
Detailsuche

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.

Handbuch für Softwareentwickler: Das Standardwerk für professionelles Software Engineering

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...

Steffo 20. Apr 2021

Klar und kurz vor Release soll dann alles nochmal durchgetestet werden, um dann...



Aktuell auf der Startseite von Golem.de
Musterfeststellungsklage
Parship kann eine Kündigungswelle erwarten

Die Verbraucherzentrale ruft zur Kündigung bei Parship und zur Teilnahme an einer Musterfeststellungsklage auf. Doch laut Betreiber PE Digital ist das aussichtslos.

Musterfeststellungsklage: Parship kann eine Kündigungswelle erwarten
Artikel
  1. Open Source: Antworten Sie innerhalb von 24 Stunden
    Open Source
    "Antworten Sie innerhalb von 24 Stunden"

    Die E-Mail eines großen Konzerns an den Entwickler von Curl zeigt wohl eher aus Versehen, wie problematisch das Verhältnis vieler Firmen zu Open-Source-Software ist.

  2. Raumfahrt: US-Weltraumstreitkräfte starten zwei Spionagesatelliten
    Raumfahrt
    US-Weltraumstreitkräfte starten zwei Spionagesatelliten

    Was können denn andere Satelliten im geostationären Orbit? Fliegen wir hin und schauen nach.

  3. Elektro-Pick-up: Neuer Tesla-Cybertruck-Prototyp gefilmt
    Elektro-Pick-up
    Neuer Tesla-Cybertruck-Prototyp gefilmt

    In einem Video wird ein neuer Cybertruck-Prototyp von Tesla im Detail gezeigt. Es stammt vermutlich aus der Gigafactory in Texas.

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 • RTX 3070 Ti 8GB 1.039€ • RX 6900XT 16 GB für 1.495€ • Acer Curved Gaming-Monitor 27" 259€ • RX 6800XT 16GB 1.229€ • Corsair 16GB DDR4-4000 111,21€ • 10% auf Gaming bei Ebay (u. a. Gigabyte 34" Curved UWQHD 144Hz 429,30€) • Razer Gaming-Stuhl 179,99€ [Werbung]
    •  /