100% Branch Coverage als persönliche Challenge: Richard Seidl spricht mit Roger Butenuth darüber, was passiert, wenn man dieses Ziel konsequent verfolgt und dabei peinliche Fehler aufdeckt, die man längst für unmöglich gehalten hatte. Butenuth berichtet von einer Sicherheitslücke in der Authentifizierung, die er erst durch die dritte Branch eines einfachen IF-Ausdrucks entdeckte, und von einem Listenfehler, der selbst die 100% unbeschadet überstand. Die beiden beleuchten, wie das Streben nach vollständiger Abdeckung den Code durch Dependency Injection und konsequentes Don't-Repeat-Yourself tatsächlich verbessert, und warum trotzdem gilt: garantierte Fehlerfreiheit gibt es nicht. Auch die Frage, ob eine Coverage-Metrik als Vorgabe überhaupt etwas bringt oder nur zum Betrügen einlädt, lässt Butenuth nicht offen.
Highlights:
- 100% Branch Coverage schützt nicht vor allen Fehlern: Ein Off-by-One-Fehler in einer kopierten Methode überlebte die vollständige Testabdeckung, weil nur null und ein Schleifendurchlauf getestet wurden, nicht mehrere.
- Eine Sicherheitslücke in der Authentifizierung, ein Variablenname statt zwei verglichen, fand Roger Butenuth nur, weil Branch Coverage alle drei Zweige einer zusammengesetzten Bedingung erzwingt, nicht bloß die Zeile.
- Testbarkeit entsteht durch Codeänderungen: Dependency Injection und klare Interfaces ermöglichten es, I/O-Fehler und Standard-Output kontrolliert im Test auszulösen, ohne Hardware-Grenzen zu treffen.
- Konsequentes Don't Repeat Yourself, erzwungen durch den Testaufwand für kopierte Zweizeiler, verbessert Lesbarkeit und Wartbarkeit, weil Änderungen nur noch an einer Stelle nötig sind.
- Eine Coverage-Metrik als Vorgabe funktioniert nicht, weil Entwickler jede messbare Schwelle erfüllen können, ohne sinnvolle Assertions zu schreiben, was die Aussagekraft der auf null senkt.
((um das Video zu sehen, muss in den Cookies den Statistiken zugestimmt werden))
-> zum Video-Podcast in voller Länge
