Vor einiger Zeit berichteten wir schon mal darüber, dass wir angefangen haben, PHPUnit-Tests zu verwenden. Inzwischen ist das fast schon ein Standard bei uns geworden – Zeit nochmal einen Einblick in etwas Spannendes zu geben…
Am Anfang steht natürlich immer die Frage: Was teste ich und wie?
Ein Test existiert schließlich nicht nur, damit am Ende alles schön grün aussieht. Vielmehr geht es darum, Schwachstellen, Edge‑Cases und unerwartete Situationen vor der Produktivsetzung abzufangen.
Die Erwartungshaltung ist klar
Ich schreibe einen Test, lasse ihn laufen und arbeite mich durch die Fehler, bis alles grün ist. Wenn ich gut bin, geht das schnell. Wenn ich schlecht bin oder Folgefehler auftreten, dauert es eben länger.
Und natürlich bringt mir ein Testpaket nur etwas, wenn ich mich nicht selbst belüge. Also: keine „nur einfachen Tests“, sondern Dinge, die realistisch auftreten können. Ein paar Beispiele:
- Nachname bleibt in einem Anmeldeformular unbelegt
- Telefonnummern in verschiedenen Schreibweisen -> wichtig! Die Frage hier ist kann mein Setup damit umgehen
- vielleicht eine nicht konforme Emailadresse
- bei API Routen und Co. durchaus mal Testen mit gültigem Auth, ungültigem Auth und keinem Auth. Kommt bei ungültigem und keinen Auth z.B. ein passender 401 bzw. 403 zurück? (Hier gern auch ein Hinweis auf unseren Artikel zum HTTP 401 vs. 403)
Gerade letzteres ist vielleicht etwas, auf das man nicht zwingend direkt kommt. Aber gerade solche Dinge sind auch wichtig, weil sie in der Realität ein Einfallstor liefern. Eine API Route die unautorisierte Zugriffe erlaubt und vielleicht sogar noch wilde Daten rausgibt – absolut undenkbar.
Aber muss man dafür immer gleich eine neue Testreihe schreiben?
Nicht unbedingt! Wir hatten zu Beginn der Entwicklung hier erst mal die API Route lokal ohne Auth hinterlegt. Das ist unsere modale Vorgehensweise: Schritt für Schritt und immer nach dem Credo Form follows function!
Was wir dann gemacht haben? Naja nachdem wir soweit waren das alle Tests „grün“ waren haben wir die Auth-Middleware aktiviert. Und dann? Einfach die Tests nochmal ausgeführt.
Natürlich waren alle Tests rot und das war auch erwartbar. Das war hier aber auch das Ziel – so konnten wir ohne neue Tests direkt sagen: Die Auth funktioniert, die Routen liefern korrekt ihr 401 zurück..
Also ja, unsere Tests waren rot.
Aber nein, das ist nicht schlimm.
Es war erwartbar – und in diesem Moment genau das, was wir wollten.
Und was sagt ein grünes Prüfergebnis aus?
Ein roter Test ist nicht automatisch ein Fehler. Aber auch ein grünes Prüfergebnis ist nicht automatisch ein Beweis für gute Software.
Ein PHPUnit-Test beantwortet immer eine konkrete Frage: Verhält sich die Anwendung unter diesen Bedingungen so, wie es erwartet wird? Ein grünes Ergebnis zeigt, dass diese Prüfung bestanden wurde. Es sagt aber nicht, ob die richtige Frage gestellt wurde oder ob wichtige Fälle außerhalb des Tests fehlen.
Das gilt auch für andere automatisierte Prüfungen. Ein Linter kann zuverlässig feststellen, ob vorher festgelegte Regeln verletzt wurden. Er kann aber nicht allein beurteilen, ob ein fachlicher Schnitt sinnvoll ist, eine Schnittstelle für ihre Nutzer verständlich bleibt oder eine formal korrekte Änderung für einen bestehenden Partner praktisch zum Bruch führt.
Genau diesen Punkt beschreibt auch Daniel Kocot in seinem Beitrag „Mehr als ein grüner Linter-Check: weitere Faktoren guter Softwareentwicklung“ bei heise Developer. Die Stärke solcher Werkzeuge liegt in ihrer Begrenzung. Sie prüfen reproduzierbar, was als Regel formuliert wurde. Die Bedeutung des Ergebnisses entsteht aber erst durch den Kontext.
Das ist keine Schwäche des Linters. Es ist sein Zweck. Maschinell prüfbare Regeln gehören in automatisierte Prüfungen. Die Einordnung eines Ergebnisses gehört in den fachlichen und architektonischen Zusammenhang. Und die Entscheidung, welches Risiko eine Organisation akzeptiert, bleibt am Ende eine menschliche Verantwortung.
Damit wird auch unser roter Test verständlicher. Nach der Aktivierung der Authentifizierung waren die Tests rot, weil sich das Verhalten der Route verändert hatte. Das rote Ergebnis war in diesem Moment kein Rückschritt, sondern der erwartete Hinweis darauf, dass die neue Schutzschicht wirksam wurde. Umgekehrt hätte ein grüner Test allein noch nicht bewiesen, dass wir alle sicherheitsrelevanten Fälle betrachtet haben.
Die Farbe des Ergebnisses ist deshalb nur ein Signal. Gute Softwareentwicklung beginnt bei der Frage, was dieses Signal im konkreten System bedeutet.
Das ist übrigens auch der Punkt, an dem sich der Bogen zu unserem Beitrag „KI erzeugt Code. Programmieren kann sie nicht.“ schließt. Code zu erzeugen oder ein Prüfergebnis zusammenzufassen ist eine Sache. Die richtigen Fragen zu stellen, fehlenden Kontext zu erkennen und Folgen abzuschätzen, ist eine andere.
Ist ein roter PHPUnit-Test immer ein Fehler?
Nein. Er kann einen echten Defekt anzeigen, aber auch eine erwartete Änderung sichtbar machen. Entscheidend ist der konkrete Entwicklungs- und Sicherheitskontext.
Beweist ein grüner Test, dass die Software gut ist?
Nein. Er zeigt nur, dass die im Test formulierte Erwartung erfüllt wurde. Nicht getestete Fälle, falsche Annahmen oder fachliche Probleme außerhalb des Tests bleiben möglich.
Was ist der Unterschied zwischen einem Test und einem Linter?
Ein Test prüft meist das Verhalten einer Anwendung unter bestimmten Bedingungen. Ein Linter prüft Quelltext oder Beschreibungen gegen festgelegte Regeln. Beide sind wertvoll, ersetzen aber keine fachliche Einordnung.
Warum ist Kontext bei Testergebnissen wichtig?
Weil dasselbe Ergebnis je nach Ziel und Änderung etwas anderes bedeuten kann. Rot kann einen Fehler oder einen erfolgreich erkannten Schutzmechanismus anzeigen. Grün kann korrekt sein und trotzdem eine wichtige Frage offenlassen.
Was hat das mit KI und Programmieren zu tun?
Auch eine KI kann Code erzeugen oder Prüfergebnisse zusammenfassen. Programmieren bedeutet zusätzlich, die richtigen Fragen zu stellen, Risiken zu erkennen und Entscheidungen im Gesamtsystem zu treffen.
Kommentar verfassen