Self-Testing – PHPUnit als Teil des Agent-Workflows
Datum: 2026-04-15
Die KI „glaubt“ – Tests wissen
Ohne erzwungene Tests ist Agent-Output Glücksspiel: grüne Chat-Antwort, rote Realität. Self-Testing bedeutet: Die Pipeline startet PHPUnit und UI-Tests automatisch – der Agent darf nicht „fertig“ sagen, ohne dass die Schichten objektiv geprüft wurden.
Das Problem
| Nur manuell testen | Folge |
|---|---|
| „Sieht gut aus“ | Regression beim nächsten Feature |
| Kein UI-Test | Layout/SEO bricht leise |
| Test abschwächen | Grün ohne Aussage |
| Keine Schicht-Trennung | Unklar wo Fehler liegt |
Die App soll sich selbst prüfen – weil der Workflow es erzwingt, nicht weil das Modell es „weiß“.
Das Pattern
Nach Code-Änderungen:
php start-vendor-phpunit-tests.php
Getrennt nach Schicht (Orchestrator im Vendor-Script):
| Schicht | Pfad | Was geprüft wird |
|---|---|---|
| Repositories | `tests/Repositories/` | SQL, Models, Indizes |
| Services | `tests/Services/` | Business-Logik, Returns |
| Orchestrators | `tests/Orchestrator/` | Step-Ketten, Models |
| UI | `tests/UI/` | WebDriver, echte URLs |
| External | `tests/External/` | Externe APIs |
Regel: Test rot → Code fixen, nicht den Test abschwächen (Projektstandard).
UI-Tests: echte Browser, echte URLs
UI-Tests öffnen Screens per WebDriver:
001. HTTP-Status und Title
002. Meta-Tags (robots, description)
003. Keine verbotenen Inline-Styles (Projektregeln)
004. Zentrale Selektoren (H1, Navigation)
Lokal: `server-start.sh`, Port aus `server-port.sh` / `config.env`. Verifikation auch per curl mit erwartetem 200.
So sieht es bei uns aus
| Script | Rolle |
|---|---|
| `start-vendor-phpunit-tests.php` | Alle Schichten nacheinander |
| `start-vendor-development-workflow.php` | Checks <strong>und</strong> Tests |
| `subagent-fix-fehler-und-test` | Reparieren bis PHPUnit + curl grün |
| `subagent-run-ui-phpunit-tests` | Nur UI-Schicht |
Der Agent-Workflow startet Tests automatisch – rot → nächste Ralph-Runde oder Fix-Subagent.
Tests + Ralph-Loop
Code-Änderung
→ subagent-check-* (statische Regeln)
→ phpunit (Laufzeit-Verhalten)
→ curl Screens (Integration)
→ OPEN_FAILURES=0
PHPUnit ist kein Ersatz für Translation-Checks – beides complementär.
Anti-Patterns
001. Tests überspringen „weil klein“ – Kleine Diffs brechen oft SEO oder Keys.
002. `assertTrue(true)` – Test ohne Aussage.
003. Mock alles – Repository-Tests sollen echte SQL-Logik treffen wo vorgesehen.
004. UI-Test ohne Server – Flaky oder wertlos.
005. Nur grüne Tests im PR, rot lokal ignorieren – Pipeline-Vertrauen weg.
Fehlender Test = fehlende Abdeckung
`subagent-check-missing-unit-tests` prüft, ob zu jedem Repo/Service/Orchestrator/Screen ein Test existiert. Neues Feature ohne Test → FAILED bis angelegt.
Häufige Fragen
Wie lange dauern alle Tests?
Je nach Projekt Minuten – Schicht-Scripts erlauben gezielten Lauf (`tests/Services/` only).
UI-Tests flaky? – Headless-Chrome, feste Selektoren, kein Sleep wo wait möglich.
Muss der Agent Tests schreiben? – Bei neuen Screens/Services laut Regeln ja; Briefing-First für Test-Briefings.
Verwandte Beiträge
| Beitrag | Thema |
|---|---|
| Ralph-Loop | Konvergenz nach Tests |
| Feature-Workflow | Akzeptanzkriterien |
| Deep-Check | Code-Qualität vor Tests |
| fix-fehler-und-test | Bis grün |
Takeaway
Die App testet sich selbst, weil der Workflow es erzwingt – nicht weil die KI es verspricht. PHPUnit nach Schichten plus UI auf echten URLs macht Agent-Output prüfbar. Wer Tests in die Pipeline legt, committet seltener Überraschungen.