Du änderst eine einzige Validierungsregel in einem FormRequest. Die CI ackert sich pflichtbewusst elf Minuten lang durch viertausend Tests, von denen ungefähr drei überhaupt einen Grund hatten zu laufen. Wir haben das alle als Preis der Zuversicht akzeptiert. Pest 5 ist das erste Major-Release in unserer Ecke des Ökosystems, das diesen Preis als verhandelbar behandelt — und, noch interessanter, das erste, das offen davon ausgeht, dass ein Teil der Diffs, die in deinem Repo landen, nie von einem Menschen getippt wurde.

Meine Position gleich vorweg: Diese Annahme stimmt, und ein Test-Framework darum herum zu bauen ist der richtige Schritt, auch wenn Teile davon schlecht altern werden. Eine Suite, die nur mit Menschen spricht, hinkt schon heute der Art hinterher, wie 2026 Code geschrieben wird. Die umstrittensten Features von Pest 5 — das Agent-Plugin und Evals — sind keine Hype-Deko. Sie sind das Eingeständnis, dass der zweite Nutzer deiner Testsuite eine Maschine ist, und dass diese Maschine genauso unverblümt gesagt bekommen muss, wenn sie danebenliegt, wie ein Junior-Dev bei seinem ersten Pull Request.

Zuerst die nüchterne Bestandsaufnahme, denn das Changelog lässt sich leicht falsch lesen. Die Mindestversion von PHP springt auf 8.4. Darunter läuft jetzt PHPUnit 13. Test Impact Analysis wählt die Teilmenge der Tests aus, die zu deinem Diff gehören, statt alles abzufeuern. PHPStan und Rector werden auf deinen Testcode losgelassen — historisch der am wenigsten analysierte Code in jedem Laravel-Repo, das ich je angefasst habe. Was keine Pest-5-Geschichte ist: Browser-Testing kam mit Pest 4, und zeitbalanciertes Sharding landete schon in 4.6. Wenn dein Upgrade-Pitch ans Team sich auf diese beiden stützt, wird das im Review zu Recht jemand anmerken.

Test Impact Analysis verdient sowohl den Applaus als auch einen Warnhinweis. Lokal macht sie aus der Gewohnheit, nach jedem Speichern Tests laufen zu lassen, statt einer Fantasie etwas, das du tatsächlich tust — und eine Gewohnheit, die du wirklich pflegst, schlägt jedes Ritual, das du auslässt. Aber überleg mal, wie viel in einer Laravel-App zur Laufzeit verdrahtet wird: Container-Bindings, die in einem Service Provider ausgetauscht werden, Listener, die in einem EventServiceProvider registriert sind, Verhalten, das über Config oder eine Morph Map umgeschaltet wird. Keine diff-basierte Auswahl kann das alles sehen. Meine Regel: betroffene Tests bei jedem Speichern, volle Suite vor dem Merge. Behandle den schnellen Pfad als Späher, nicht als Urteil.

Beim Agent-Plugin gehen die Meinungen an Konferenz-Bars auseinander. Die Idee: Ein Coding-Assistent soll seine Hausaufgaben nicht selbst benoten, indem er seinen Diff noch mal durchliest — er soll seine Behauptungen gegen eine hochgefahrene Anwendung prüfen können. Hat die Migration die Spalte wirklich angelegt? Liegt der Job nach dem Request tatsächlich in der Queue? Das ist keine KI-Anbetung; das ist die älteste Regel, die wir haben — vertraue nicht, verifiziere — angewandt auf eine neue Sorte Contributor. Evals dehnen dieselbe Ehrlichkeit auf die Modellausgabe selbst aus: Wenn die Antwort legitimerweise zwischen Läufen variiert, prüfst du Eigenschaften und Grenzen, statt so zu tun, als würde assertSame() die Sache klären.

Jetzt das stärkste Argument gegen mich, fair formuliert. Erstens: Die Anforderung PHP 8.4 ist eine echte Wand. Genug Teams fahren in Produktion 8.2 oder 8.3, aus Gründen, die nichts mit Faulheit zu tun haben — Vendor-Images, Compliance-Freezes, diese eine Extension, die niemand neu zu kompilieren wagt. Für sie ist Pest 5 ein Gespräch für 2027, und das ist okay. Zweitens: Test-Frameworks haben ein langes Gedächtnis, und Werkzeuge für den Workflow von diesem Jahr anzuschrauben birgt das Risiko, in fünf Jahren toten Ballast mitzuschleppen. Vielleicht überleben Evals in ihrer jetzigen Form nicht. Ich gehe das Risiko trotzdem ein, denn die Alternative — eine Testing-Story, die ignoriert, wie Patches in meinem Team gerade wirklich entstehen — kostet mich dieses Quartal mehr, als mich ein deprecatetes Plugin später kostet.

Worauf ich immer wieder zurückkomme: Nichts davon ändert, was ein Test ist. Es ändert, wer das rote X liest. Wenn der Leser ein Mensch ist, ist ein Fehlschlag Feedback. Wenn der Leser ein Agent ist, ist ein Fehlschlag eine Leitplanke — das Einzige, was zwischen einem selbstbewusst klingenden Patch und deinem main-Branch steht. Mir ist ein Framework lieber, das diese zweite Rolle ernst nimmt, als eines, das so tut, als wäre noch 2019.

Also, Kollegen, zwei Fragen, auf die ich ernsthaft Antworten in den Kommentaren will: Würdest du einen Merge jemals nur auf Basis der betroffenen Tests durchwinken — oder ist die volle Suite vor main in deinem Laden nicht verhandelbar, egal wie gut die Auswahl wird? Und hast du schon wirklich einen Assistenten unbeaufsichtigt deine Tests laufen lassen, oder drückt bei euch noch ein Mensch auf den Knopf? Sag mir, wo deine Grenze liegt — und warum.