‹ Alle Artikel

Wenn die eigene Prüfung sich grünes Licht gibt

Eine Build-Prüfung meldete nie einen Fehler. Nicht weil alles stimmte, sondern weil sie ihren eigenen Kommentar fand. Über das Eichen von Prüfungen.

Eine Build-Prüfung sollte sicherstellen, dass auf jeder ausgelieferten Seite der Herkunftsvermerk steht. Sie lief bei jedem Build mit und meldete nie etwas.

Das lag nicht daran, dass alles in Ordnung war. Sie hätte auch nichts gemeldet, wenn der Vermerk komplett gefehlt hätte.

Die Prüfung fand ihren eigenen Kommentar

['webliq.de', 'Herkunftsvermerk']   // wirkungslos

Gesucht wurde nach der Zeichenkette webliq.de im fertigen HTML. Die stand dort auch — aber in einem CSS-Kommentar, der erklärte, warum das Logo nicht von dieser Domain geladen wird.

Die Prüfung fand ihren Treffer und war zufrieden. Sie hätte sich dauerhaft selbst grünes Licht gegeben.

Der Eichtest, der es aufdeckte

Wir haben den Vermerk absichtlich aus der Fußzeile entfernt und den Build laufen lassen. Er lief durch. Damit war klar: Die Prüfung prüft nichts.

Die Korrektur bestand darin, nicht auf einen Namen zu prüfen, sondern auf die Form, die die Sache im Ergebnis annimmt:

['href="https://webliq.de"', 'Herkunftsvermerk']   // schlägt an

Ein Kommentar enthält kein href="…". Nach der Änderung brach derselbe Eichtest den Build ab — wie er sollte.

Warum das gerade sorgfältige Projekte trifft

Je gründlicher man Entscheidungen im Code kommentiert, desto wahrscheinlicher enthält das Ergebnis den gesuchten Begriff an einer Stelle, die nichts beweist. Besonders betroffen sind Generatoren, die ihre Kommentare in die Ausgabe schreiben — dort landet die Begründung, warum etwas nicht getan wird, im selben Dokument wie der Beweis, dass es getan wurde.

Der Fehler ist unsichtbar, weil er sich als Erfolg tarnt. Eine Prüfung, die nie meldet, wirkt wie eine erfüllte Anforderung.

Was wir daraus mitnehmen

Zwei Regeln haben wir daraus gemacht. Erstens: nie auf einen nackten Begriff prüfen, sondern auf eine Struktur — ein vollständiges Attribut, ein Tag, eine ID.

Zweitens, und wichtiger: Jede neue Prüfung wird geeicht, bevor wir ihr glauben. Das Geprüfte kaputt machen, Build laufen lassen, Abbruch sehen, zurücksetzen. Eine Prüfung, die noch nie ausgelöst hat, ist keine Prüfung, sondern eine Behauptung.

Projekt im Kopf?

Wenn Sie an ähnlichen Problemen sitzen — wir bauen Software, die solche Fallen umgeht.

✉ contact@otaku-development.de