##  Pfadnavigation

1. [ Startseite ](/)
2. [ Software Testing & Qualität - Testautomatisierung, KI & Agilität ](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)
3. Roger Butenuth: Warum 100 Prozent Coverage keine Fehlerfreiheit garantiert

# Roger Butenuth: Warum 100 Prozent Coverage keine Fehlerfreiheit garantiert

            **Podcast:**

   [Software Testing & Qualität - Testautomatisierung, KI & Agilität](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)

              **Erscheinungsdatum:**

   25. August 2026

            **Länge:**

   00:20:06

    [         Link zur Episode (extern)   ](https://www.richard-seidl.com/de/podcast/grenzen-code-coverage-metrik)

 ![Warum vollständige Coverage keine Fehlerfreiheit garantiert - Roger Butenuth](https://www.botcaster.de/sites/default/files/styles/podcast_n_episode_metadata_image_1x/public/2026-08/b526c45f-5a70-4d3a-96f3-385d4cede828.jpg.webp?itok=C6ZPmH2F)

###   Warum vollständige Coverage keine Fehlerfreiheit garantiert - Roger Butenuth

   25. August 2026 · [Software Testing & Qualität - Testautomatisierung, KI & Agilität](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)

Kann 100 % Branch Coverage wirklich absolute Fehlerfreiheit garantieren? Roger Butenuth hat dieses Ziel konsequent an einem selbstgeschriebenen Lisp-Interpreter verfolgt und dabei überraschende Fehler, darunter eine handfeste Sicherheitslücke, entdeckt. In der Episode des Podcasts *[Software Testing & Qualität](https://www.botcaster.de/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)* spricht Host Richard Seidl mit seinem Gast Roger Butenuth über dieses außergewöhnliche Experiment. Sie diskutieren, welche peinlichen Fehler dabei ans Licht kamen, warum trotz vollständiger Abdeckung ein Bug unentdeckt blieb und was das Streben nach Testbarkeit für die Code-Qualität bedeutet. Diese Folge bietet tiefe Einblicke für Entwickler:innen und Tester:innen, die den wahren Wert von Testmetriken und die Kunst des Schreibens von testbarem Code verstehen wollen.

## Das Wichtigste auf einen Blick

- **Ein persönliches Experiment:** Roger setzte sich die Herausforderung, für einen selbst geschriebenen Interpreter einer Lisp-ähnlichen Sprache in Java eine 100-prozentige Branch Coverage durch Unit-Tests zu erreichen.
- **Fehler an unerwarteten Stellen:** Das konsequente Testen deckte gravierende Fehler in Code-Abschnitten auf, die Roger selbst für zu trivial hielt, um fehleranfällig zu sein - darunter eine kritische Sicherheitslücke in der Authentifizierungslogik.
- **100 % Coverage ist keine Garantie:** Trotz der vollständigen Abdeckung aller Code-Pfade blieb ein Fehler in der Listenimplementierung unentdeckt. Dieser trat erst bei mehrfachen Schleifendurchläufen auf und wurde nur durch die praktische Anwendung im Rahmen des Advent of Code gefunden.
- **Testbarkeit verbessert Code-Qualität:** Um die 100 % zu erreichen, musste Roger seinen Code umfassend refaktorisieren und testbar machen, vor allem durch den Einsatz von Dependency Injection. Dieser Prozess führte zu flexiblerem, modularerem und besser wartbarem Code.
- **Metriken sind kein Allheilmittel:** Eine hohe Code Coverage allein ist wertlos ohne aussagekräftige Assertions in den Tests. Starre prozentuale Vorgaben können dazu verleiten, die Metrik zu manipulieren, anstatt die Qualität wirklich zu verbessern.
- **Aufwand und Ergebnis:** Das Verhältnis von Produktivcode zu Testcode lag bei diesem Projekt am Ende bei etwa eins zu eins, was den erheblichen Aufwand für eine derart hohe Testabdeckung verdeutlicht.

## Das persönliche Experiment: 100 % Branch Coverage für einen Lisp-Interpreter

Den Anstoß für das ehrgeizige Projekt gab eine besonders komplexe Komponente des von Roger Butenuth entwickelten Lisp-Interpreters: eine selbst entworfene, persistente Listenstruktur. Im Gegensatz zu Standardimplementierungen wie der `ArrayList` in Java oder der `SingleLinkedList` in Scala, die für seinen Anwendungsfall entweder nicht persistent oder zu ineffizient waren, entwickelte er eine eigene Lösung auf Basis eines zweidimensionalen Arrays mit exponentiell wachsenden Subarrays. Die Implementierung dieser Struktur war jedoch extrem anfällig für sogenannte Plus-Minus-Eins-Fehler. Um diese Fehlerquelle systematisch auszuschließen, begann Roger, die Listenfunktionen äußerst gründlich zu testen, und erreichte dabei schnell eine hohe Testabdeckung. An diesem Punkt packte ihn der Ehrgeiz: Er beschloss, dieses Ziel auf den gesamten Interpreter auszuweiten und eine vollständige Branch Coverage von 100 % anzustreben.

## Wie macht man Code vollständig testbar?

Um jeden einzelnen Zweig im Code zu erreichen, musste Roger tief in die Architektur seiner Anwendung eingreifen. Einfachere Teile wie rein funktionale, zustandslose mathematische Operationen ließen sich unkompliziert testen. Die Herausforderung wuchs jedoch mit Komponenten, die von externen Systemen abhängig sind, wie bei I/O-Operationen (Lesen und Schreiben von Dateien) oder dem integrierten HTTP-Client und -Server. Um beispielsweise Fehlerfälle wie eine volle Festplatte zu simulieren, ohne diese real herbeizuführen, setzte Roger konsequent auf Dependency Injection. Statt direkt auf das Dateisystem zuzugreifen, übergab er den Funktionen Interfaces wie einen Java-Reader. Im Test konnte er so eine Mock-Implementierung einreichen, die gezielt eine `IOException` auslöst. Ähnlich ging er bei der Überprüfung von Konsolenausgaben (`System.out`) vor, indem er den Standard-Print-Stream durch eine eigene Implementierung austauschte, deren Inhalt er im Test auslesen konnte. Dieser Prozess zwang ihn, seinen Code so umzugestalten, dass er testbarer wurde. Da er in diesem privaten Projekt sein eigener Product Owner war, konnte er diese Änderungen ohne externe Widerstände umsetzen - ein Luxus, der in Unternehmensprojekten nicht immer gegeben ist.

## Die überraschenden Funde: Eine Sicherheitslücke und die Grenzen der Metrik

Das Streben nach vollständiger Coverage förderte Fehler an Stellen zutage, die man leicht übersehen würde. Der gravierendste Fund war eine Sicherheitslücke in der Basic-Authentication-Funktion eines Webservice. In der Methode zum Vergleich von Benutzername und Passwort hatte Roger versehentlich den übergebenen Benutzernamen mit sich selbst verglichen (`this.user` statt `user`). Der Fehler fiel nur auf, weil er zur Erreichung der 100 % auch die Testfälle für die nicht erfolgreiche Authentifizierung schreiben musste und dabei auf unerwartetes Verhalten stieß. Dieser Fund ist ein eindrückliches Beispiel dafür, dass Fehler oft in scheinbar trivialem Code lauern.

Gleichzeitig zeigte das Experiment aber auch die Grenzen der Metrik auf. Nachdem die 100 % erreicht waren, nutzte Roger seinen Interpreter, um an der Programmier-Challenge Advent of Code teilzunehmen. Dabei stieß er auf einen Fehler in seiner hochgelobten Listenimplementierung. Eine `while`-Schleife funktionierte für null und einen Durchlauf korrekt - beides war durch Tests abgedeckt. Der Fehler trat jedoch erst beim zweiten Durchlauf auf, weil ein Indexwert falsch manipuliert wurde. Ein klassischer Copy-Paste-Fehler, der zeigte: 100 % Branch Coverage garantieren nicht, dass alle logischen Fehler oder zustandsbasierten Probleme über mehrere Iterationen hinweg gefunden werden.

## Warum eine reine Coverage-Vorgabe nicht zielführend ist

Roger und Richard sind sich einig, dass das blinde Verfolgen einer prozentualen Coverage-Vorgabe in Projekten mehr schaden als nutzen kann. Jede Metrik, die als Ziel vorgegeben wird, kann und wird manipuliert. Entwickler:innen könnten versucht sein, Tests zu schreiben, die zwar den Code ausführen, aber keine sinnvollen Überprüfungen (Assertions) enthalten, nur um die Kennzahl zu erreichen. Eine hohe Coverage ist nur dann wertvoll, wenn die zugrundeliegenden Tests auch wirklich das korrekte Verhalten des Systems verifizieren. Statt starrer Vorgaben sollte an die Vernunft und das Verantwortungsbewusstsein des Teams appelliert werden. Die Entscheidung, wie intensiv ein bestimmter Teil des Codes getestet werden muss, sollte von dessen Kritikalität und Komplexität abhängen, nicht von einer abstrakten Zahl.

## Praktische Lehren aus dem Experiment

Aus Rogers tiefgreifendem Experiment kannst Du mehrere wertvolle Erkenntnisse für Deine eigene Arbeit im Bereich Softwareentwicklung und -qualitätssicherung ziehen:

1. **Misstraue trivialem Code:** Die gravierendsten Fehler können sich dort verstecken, wo Du sie am wenigsten erwartest. Widme auch einfachen Logik-Blöcken wie Authentifizierungs-Checks die nötige Aufmerksamkeit beim Testen.
2. **Setze auf testbares Design:** Nutze Prinzipien wie Dependency Injection nicht nur, um Tests zu ermöglichen, sondern auch, um Deinen Code flexibler und modularer zu gestalten. Gut testbarer Code ist oft auch qualitativ hochwertigerer Code.
3. **Denke über Schleifengrenzen hinaus:** Wenn Du Schleifen testest, beschränke Dich nicht nur auf die Fälle null Durchläufe und ein Durchlauf. Ein dritter Testfall für mehrere Durchläufe kann Fehler aufdecken, die durch zustandsverändernde Operationen innerhalb der Schleife entstehen.
4. **Hinterfrage Metriken kritisch:** Eine hohe Code Coverage ist ein nützlicher Indikator, aber kein Selbstzweck. Viel wichtiger sind die Qualität und die Aussagekraft Deiner Tests. Ein Test ohne eine sinnvolle Assertion ist wertlos, egal wie viel Code er abdeckt.
5. **Don't Repeat Yourself (DRY) konsequent anwenden:** Die Auslagerung von wiederkehrenden Code-Schnipseln in eigene kleine Funktionen reduziert nicht nur Redundanz, sondern senkt auch den Testaufwand, da die Logik nur an einer einzigen Stelle geprüft werden muss.

---

 version="1.0" encoding="UTF-8"?
      .st0 {
        fill: #010101;
      }

      .st1 {
        fill: #b0c0b3;
      }

      .st2 {
        fill: #3b3a3b;
      }

      .st3 {
        fill: #3a3a3a;
      }

      .st4 {
        fill: #5e7185;
      }

      .st5 {
        fill: #f9eddd;
      }

      .st6 {
        fill: #000100;
      }

      .st7 {
        fill: #aebeb3;
      }

      .st8 {
        fill: #fefefe;
      }

      .st9 {
        fill: #7f93a8;
      }

      .st10 {
        fill: #f8f0df;
      }

      .st11 {
        fill: #fbf0df;
      }

      .st12 {
        fill: #afbfb2;
      }

      .st13 {
        fill: #f7eedd;
      }

      .st14 {
        fill: #fdfdfd;
      }
                                                                                   Botcaster

  **Zusammengefasst von Anja Schirwinski**

Ich beschäftige mich beruflich wie privat mit Künstlicher Intelligenz - von konkreten Tools im Arbeitsalltag bis zu den größeren Fragen, die dabei aufkommen. Viele der Themen, die in Podcasts besprochen werden, begegnen mir in Projekten immer wieder. Deshalb fasse ich hier die für mich interessantesten Podcastfolgen zusammen und ordne sie aus der Praxis ein.

[Mehr über das Projekt Botcaster](/ueber-uns)

##  Themen

 - [  Softwareentwicklung mit KI  ](/podcasts/themen/softwareentwicklung-mit-ki)
- [  Testen und Qualität  ](/podcasts/themen/testen-qualitaet)

**Hinweis:** *Diese Zusammenfassung wurde mit Hilfe von KI aus dem Transkript der Podcast-Episode generiert.*

Alle Inhalte auf Botcaster beruhen auf öffentlich zugänglichen Podcasts rund um Künstliche Intelligenz. Wir fassen die Episoden nach bestem Wissen zusammen, übernehmen jedoch keine Gewähr für Vollständigkeit, Aktualität oder Richtigkeit der Inhalte. Die Rechte an den Original-Podcasts und -Inhalten liegen ausschließlich bei den jeweiligen Urheber:innen.

         ## Shownotes

   Kann man mit 100% Branch Coverage wirklich sicherstellen, dass Code fehlerfrei ist? Mit Roger Butenuth spreche ich darüber, was passiert, wenn man dieses Ziel konsequent verfolgt, und zwar nicht als theoretische Übung, sondern an einem echten, selbst geschriebenen Interpreter für eine Lisp-ähnliche Sprache. Roger erzählt, welche peinlichen Fehler er dabei entdeckt hat, darunter eine handfeste Sicherheitslücke an einer Stelle, die er für zu trivial hielt, um dort einen Bug zu vermuten. Und trotzdem blieb am Ende noch ein Bug übrig, der erst beim Advent of Code auftauchte.