Nachdem wir in Teil 3 die Absurdität architektonischer Prinzipien erlebt haben mit Standards, die niemand kannte, und SOLID-Regeln aus zweiter Hand, steigen wir nun eine Ebene tiefer in die seelischen Abgründe einer Branche hinab, die Testing nicht als Werkzeug, sondern als Religion betreibt.
In Teil 4 geht es um das große Missverständnis moderner Softwarequalität: Tests, die alles testen außer Sinn. Code-Reviews, die mehr über zwischenmenschliche Dynamiken verraten als über Codequalität. Und Entwickler, die den Dunning-Kruger-Effekt so fest in ihren Build-Prozess integriert haben, dass sie ihn für ein Feature halten.
Teil 4 – Testing & Reviews in der Entwicklerhölle
„Tests gab es. Vertrauen nicht.“
Aus dem Alltag zwischen Code-Coverage, Mocks und der Illusion von Sicherheit
Testing als Glaubensfrage
Tests gab es, zumindest im Ordner tests/.
Isoliert? Keineswegs.
Jeder Test zog das komplette Framework hoch.
Und weil Singleton-Instanzen verwendet wurden, waren die Tests voneinander abhängig.
Unit-Tests? Eher Integrationstests mit Einbildung.
Es wurde sogar behauptet:
„Sebastian Bergmann hat das so empfohlen.“
(Hinweis: Sebastian Bergmann ist der Autor von PHPUnit – siehe offizielle Webseite)
Fun-Fact:
Ich war bei einer Schulung als auch auf Entwickler-Konferenzen.
Er würde sowas niemals sagen. Wirklich. Niemals.
Man testete alles, was ging am liebsten mit Mocks.
Aber nicht etwa, um Verhalten zu isolieren,
sondern um sicherzustellen, dass jede intern aufgerufene Methode auch ja wirklich aufgerufen wurde.
Ob das Ergebnis korrekt war?
Nebensache.
Und wenn es dann mal wirklich relevant wurde, etwa bei selbstgeschriebenen ORM-Abfragen mit eingebettetem SQL kam reflexartig die Ausrede:
„Wir testen das Framework nicht.“
Dabei war der SQL-String komplett von Hand zusammengebaut inmitten eines ORM-Layers, der genau das eigentlich abstrahieren sollte.
Ob ein Join überhaupt existierte?
Ob ein Filter korrekt gesetzt wurde?
Wollte man gar nicht wissen.
War ja Framework.
Auch Kindklassen, die auf abstrakten Basisklassen des Frameworks aufbauten und dabei eigene Logik enthielten wurden nicht getestet.
„Das ist ja vererbter Code -> also Framework.“
Dass die Logik von uns kam, spielte keine Rolle innerhalb dieser Entwickler Hölle.
Die Vererbung diente als Test-Immunisierung.
Es gab auch jene besonderen Stellen in Projekten, bei denen die unumstößliche Diagnose lautete:
„Kann man nicht testen.“
Warum? Gute Frage.
Vielleicht, weil die Klassen so hermetisch abgeschlossen waren, dass sie ihre Zustände aus fünf verschiedenen Singletons bezogen -> gleichzeitig.
Oder weil sie bei jedem Aufruf stillschweigend eine Kaskade veralteter Datenbank-Migrationen starteten, die längst gelöscht, aber nie entfernt wurden.
Unit-Test? Unmöglich.
Nicht wegen fehlender Tools sondern wegen strukturellem Selbstschutz auf Klassenebene.
Die Lösung? Ganz einfach:
Ein elegantes // @codeCoverageIgnore über die Klasse und schon war alles gut.
Kein Refactoring, kein Nachdenken, Kein Test.
Nur Stille. Und ein schöner grüner Balken im Coverage-Bericht.
Denn was ignoriert wird, ist auch kein Problem.
So einfach ist das in der Hölle.
Was das für normale Menschen bedeutet
Stell dir vor, du gehst zum TÜV mit deinem Auto. Aber statt zu prüfen, ob das Auto wirklich sicher fährt, wird nur kontrolliert, ob beim Starten alle Lampen einmal kurz blinken weil das als „Test“ gilt. Die Bremsen? Egal. Hauptsache, die Hupe wurde einmal betätigt.
So ungefähr lief das mit den Tests in diesem Projekt.
Es gab sie – also optisch. In einem Ordner lagen sie fein sortiert. Doch in Wirklichkeit war es, als würde man jedes Mal die ganze Werkstatt auseinanderbauen, nur um zu prüfen, ob das Radio angeht.
Manche Tests waren dermaßen verkettet, dass sie sich gegenseitig beeinflussten wie wenn du erst den Kühlschrank einschalten musst, damit die Heizung funktioniert. Warum? Weil alles auf merkwürdige Weise miteinander verbunden war.
Und wenn jemand fragte: „Ist das wirklich sinnvoll?“ lautete die Antwort oft: „Das wurde so empfohlen.“ Angeblich vom Experten. Der hätte sich vermutlich nur an den Kopf gefasst.
Noch absurder war es bei echten Problemen: Wenn eine Datenbank-Abfrage nicht funktionierte, sagte man einfach: „Das testen wir nicht das ist vom System.“ Auch wenn man sie selbst geschrieben hatte.
Manche Teile wurden bewusst nicht geprüft mit dem digitalen Äquivalent zu: „Bitte hier nicht nachsehen.“ Einfach eine kleine Notiz am Code, die sagt: „Ignorieren, das ist normal so.“
Und der Grund, warum viele Teile nicht testbar waren? Weil sie so gebaut wurden, dass sie sich selbst schützen. Wie ein Tresor, den man nur mit fünf gleichzeitig eingesetzten Schlüsseln öffnen kann wobei einer davon längst verloren ist.
Am Ende war alles schön grün im Prüfbericht also angeblich „vollständig getestet“. In Wahrheit hatte man einfach gesagt: „Wir schauen da gar nicht erst hin.“ Und dann gehofft, dass es schon gut geht.
Code-Reviews als Geduldsprobe
Code-Reviews waren formale Akte.
Ein Pull Request mit 100 Zeilen? Zwei Tage Bearbeitungszeit.
Nicht, weil der Code komplex war
sondern weil er durch das kollektive Halbwissen erstmal entschlüsselt werden musste.
Architekturprinzipien gab es: nur halt selbst erfundene.
Der Dunning-Kruger-Effekt hatte dort nicht nur Hausrecht
er hatte einen eigenen Tisch in der Cafeteria.
Stell dir vor, du musst ein einfaches Rezept abgeben sagen wir: ein Rührei.
Doch bevor du es servieren darfst, muss es durch ein Komitee aus Hobbyköchen, die alle ihre eigene Vorstellung davon haben, wie ein Ei zu sein hat.
- Der eine besteht auf Bio-Eiern.
- Der nächste auf Pfannen aus Gusseisen.
- Wieder einer glaubt, dass Rührei nur funktioniert, wenn man es rückwärts anrührt.
Statt zu prüfen, ob das Ei schmeckt,
diskutiert man über die Farbe des Tellers.
Und während dein Teller langsam kalt wird,
sitzt ganz hinten ein Typ, der noch nie selbst gekocht hat,
aber sicher ist, dass man Eigelb nicht essen sollte.
Willkommen beim Code-Review.
Ankündigung für Teil 5:
Ankündigung für Montag um 13:37 Uhr – Teil 5 ist der Abgesang auf das große Ganze auf Systeme, die alles miteinander verbinden wollten und dabei jedes Prinzip geopfert haben, das man einst für sinnvoll hielt. Integration? Das bedeutete hier nicht Zusammenspiel, sondern Dämonenbeschwörung mit YAML, Singleton und Tokenmagie.
Was bleibt, ist eine Welt aus strukturiertem Wahnsinn, dokumentiertem Vergessen und Interfaces, die lügen. Willkommen beim Kapitel: Dort, wo selbst Fluchtwegschilder besser gewartet sind als der Code.
Rechtlicher Hinweis (Stand: 2025)
Dieser Text ist eine satirisch überzeichnete Verarbeitung beruflicher Erfahrungen aus verschiedenen anonymisierten Projekten. Alle geschilderten Szenen, Dialoge und technischen Konstellationen sind abstrahiert und dienen ausschließlich der Reflexion wiederkehrender Muster in der Softwareentwicklung. Sämtliche technische Beschreibungen sind abstrahiert und stellen keine Rückschlüsse auf konkrete Systemarchitekturen oder Sicherheitsrisiken von Projekten/Unternehmen/Open-Source-Projekten/Aufträgen dar.
Dieser Artikel stellt keine Tatsachenbehauptung über reale Organisationen oder Projekte dar und erhebt keinen Anspruch auf Vollständigkeit oder Objektivität. Die Inhalte sind durch Art. 5 Abs. 1 GG (Meinungs- und Kunstfreiheit) geschützt.
