• IT-Karriere:
  • Services:

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. über grinnberg GmbH, Bruchsal
  2. Berliner Wasserbetriebe, Berlin-Wilmersdorf

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.  


Anzeige
Top-Angebote
  1. 52,99€
  2. (u. a. Samsung GQ65Q700T 65 Zoll 8K für 1.199€, LG OLED65BX9LB 65 Zoll OLED für 1.555€)
  3. (u. a. AMD Ryzen 5 5600X für 294€ + 6,99€ Versand und Biostar B550M-Silver für 109,90€ + 6...
  4. 229,90€ + 5,99€ Versand bei Vorkasse (Vergleichspreis 261,01€ inkl. Versand)

Robert.Mas 21. Apr 2021 / Themenstart

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

kayozz 21. Apr 2021 / Themenstart

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

Steffo 20. Apr 2021 / Themenstart

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

Steffo 20. Apr 2021 / Themenstart

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

Steffo 20. Apr 2021 / Themenstart

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

Kommentieren


Folgen Sie uns
       


Fotos kolorieren mit einem Klick per KI - Tutorial

Wir zeigen, wie sich ein altes Bild schnell kolorieren lässt - ganz ohne Photoshop.

Fotos kolorieren mit einem Klick per KI - Tutorial Video aufrufen
Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme

      •  /