Symfony AI Mate: CLI Assistent für PHP
Symfony AI Mate ist der CLI Assistent für KI gestützte PHP Entwicklung. Seit 0.13 ohne MCP Server, 0.14 bringt neue Tools. Installation, Skills, Setup.
Mehr erfahren- Aktualisiert:
- Autor:
- Roland Golla
PHP Error Log: Definition
Das PHP Error Log ist die Datei oder der Kanal, in den PHP Fehler, Warnungen, Notices und Deprecations schreibt. Gesteuert wird es über die php.ini Direktiven log_errors, error_log und error_reporting.
In Production ist das Error Log oft die einzige Stelle, an der du erfährst, was wirklich passiert ist. Der Besucher sieht eine neutrale Fehlerseite, das Log bekommt Meldung, Datei, Zeile und seit PHP 8.5 auch den Stack Trace eines Fatal Errors. Wer sein Error Log sauber einrichtet und regelmäßig liest, findet Bugs, bevor Kunden sie melden.
Inhalt
NCA KI Workshop für Developer
Agentic Coding im Team, nicht nur im Glossar
Ein Tag inhouse mit Benjamin Klein für Developer, Tester und Admins. Context Engineering, Harness, ADRs und zwei Hands on Blöcke mit KI Agenten in eurem Setup.
-
1Kostenloses VorgesprächStand, Rollen und Ziele klären
-
2Workshoptag bei euchPraxis am Vormittag, Hands on danach
-
3Praxistag optionalAgenten im eigenen Projekt
Benjamin Klein
Senior Consultant
PHP Error Log mit NCA: Schnelle Hilfe vom Experten
Fehler sauber sichtbar machen gehört zu unserem Alltag. Wir betreiben Symfony und Sulu Anwendungen auf eigenen Servern in Deutschland, loggen mit Monolog und überwachen mit Sentry und Grafana. Roland Golla arbeitet seit über 20 Jahren an Testing und Refactoring in PHP Projekten. Wir wissen, welche Log Zeile nach einem Deployment zählt und welche nur Rauschen ist.
Teams begleiten wir im PHP Consulting und im Refactoring Workshop. Wenn aus dem Error Log ein Performance Thema wird, helfen Xdebug und SPX beim Profiling. Deprecations vor einem Upgrade räumen Rector und PHPCompatibility auf. Wie Coding Agents deine Logs lesen, zeigt Symfony AI Mate.
PHP Error Log aktivieren: die wichtigsten php.ini Einstellungen
Vier Direktiven entscheiden, ob und wo PHP Fehler festhält. Die Grundregel ist einfach: Fehler immer loggen, nie im Browser zeigen. Für Production sieht eine solide Basis so aus:
Code:
; php.ini für Production
error_reporting = E_ALL
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app_error.log
zend.exception_ignore_args = On
error_reporting = E_ALL meldet alles, auch Deprecations. Du filterst später im Log, nicht schon in PHP. display_errors = Off verhindert, dass Pfade, SQL oder Zugangsdaten im Browser landen. error_log braucht einen absoluten Pfad, auf den der PHP Prozess schreiben darf. Fehlt die Direktive, landen die Meldungen bei PHP FPM im FPM Log, beim Apache Modul im Webserver Log und im CLI auf stderr.
Lokal drehst du nur eine Schraube um: display_errors = On. In DDEV oder Docker lohnt sich zusätzlich error_log = /dev/stderr. Dann siehst du jeden Fehler direkt in den Container Logs.
Zur Laufzeit kannst du einzelne Werte mit ini_set() überschreiben, etwa ein eigenes Log für einen Cronjob. Für die globale Konfiguration bleibt die php.ini die bessere Wahl. Sie greift schon beim Start von PHP und erfasst damit auch Fehler, bevor dein Code überhaupt läuft.
Entwicklung und Production im Vergleich
Wo liegt das PHP Error Log?
Die häufigste Frage zum Error Log ist nicht wie, sondern wo. Die Antwort hängt davon ab, wie PHP läuft. Statt zu raten, fragst du PHP direkt:
Code:
# Welche php.ini ist geladen und wohin wird geloggt?
php --ini
php -i | grep -E 'error_log|log_errors|display_errors'
# Seit PHP 8.5: nur Werte, die vom Default abweichen
php --ini=diff
# Live mitlesen
tail -f /var/log/php/app_error.log
Wichtig: CLI und Webserver nutzen oft unterschiedliche php.ini Dateien. Ein Cronjob kann also in eine ganz andere Datei schreiben als dein Webshop. Im Browser Kontext hilft ein kurzer Check mit ini_get('error_log') in einer geschützten Admin Route, nie in einer öffentlich erreichbaren phpinfo Datei.
Typische Fundorte ohne eigene error_log Direktive:
- PHP FPM: das Log des jeweiligen Pools, oft unter /var/log/php*-fpm.log
- Apache mit mod_php: das Apache Error Log des VirtualHosts
- CLI: stderr, also direkt im Terminal oder im Cron Mail
- Container und FrankenPHP: stdout und stderr, abrufbar über die Container Logs
Error Levels lesen und richtig einordnen
Jeder Eintrag im Error Log trägt ein Level. Daran erkennst du, ob du sofort handeln musst oder ob es Zeit bis zum nächsten Sprint hat.
- Fatal Error (E_ERROR, E_PARSE, E_COMPILE_ERROR): Das Script bricht ab. Hier verliert jemand gerade eine Bestellung oder ein Formular.
- Warning (E_WARNING): Der Code läuft weiter, liefert aber oft falsche Daten. Klassiker: fehlende Datei, falscher Array Key.
- Notice (E_NOTICE): Kleinigkeiten, die oft auf echte Logikfehler zeigen.
- Deprecated (E_DEPRECATED, E_USER_DEPRECATED): Läuft heute, bricht im nächsten Major Release. Das ist deine Upgrade Liste.
Zwei Änderungen aus PHP 8.4 betreffen viele ältere Setups. Die Konstante E_STRICT ist deprecated, weil das Level seit PHP 8.0 nicht mehr genutzt wird. Aus E_ALL | E_STRICT wird einfach E_ALL. Außerdem ist trigger_error() mit E_USER_ERROR deprecated. Statt einen eigenen Fatal Error auszulösen, wirfst du eine Exception.
Best Practices für das PHP Error Log in Production
Ein Error Log hilft nur, wenn jemand es liest und die Einträge etwas taugen. Diese Regeln setzen wir in jedem Projekt um:
- E_ALL loggen, gezielt filtern. Wer Notices schon in der php.ini abschaltet, sieht die Vorboten echter Bugs nicht.
- Nie im Browser anzeigen. display_errors bleibt in Production aus. Fehlerseiten zeigen eine Referenz ID, die Details stehen im Log.
- Log Rotation einrichten. Ein Error Log ohne logrotate wächst, bis die Platte voll ist. Dann loggt gar nichts mehr.
- Keine Geheimnisse im Log. Markiere Passwörter und Tokens in Funktionssignaturen mit #[\SensitiveParameter] und setze zend.exception_ignore_args. Das hilft auch beim Datenschutz.
- Strukturiert statt Freitext. JSON Zeilen mit Request ID, Umgebung und Release lassen sich filtern, zählen und an Grafana weitergeben.
- Den @ Operator vermeiden. Unterdrückte Fehler verschwinden aus dem Log und tauchen später als Rätsel wieder auf.
- Alarm bei Fatal Errors. Neue Fatal Errors nach einem Deployment gehören sofort ins Team, nicht in den Wochenreport.
- Deprecations sammeln, nicht ignorieren. Ein eigener Kanal für Deprecations ist die beste Vorbereitung auf das nächste PHP Upgrade.
Eine Sache unterschätzen viele Teams: Das Log sollte nach einem sauberen Deployment leer bleiben. Jeder Eintrag, den alle ignorieren, versteckt den einen, der wichtig ist.
Eigener Error Handler: Warnings zu Exceptions machen
In Anwendungen ohne Framework lohnt sich ein zentraler Error Handler. Er wandelt Warnings und Notices in Exceptions um, loggt Deprecations separat und fängt Fatal Errors beim Shutdown ab. So landet jeder Fehler auf genau einem Weg im Log.
Code:
set_error_handler(function (int $severity, string $message, string $file, int $line): bool {
if (!(error_reporting() & $severity)) {
return false;
}
// Deprecations nur loggen, nicht abbrechen
if ($severity & (E_DEPRECATED | E_USER_DEPRECATED)) {
error_log(sprintf('[deprecated] %s in %s:%d', $message, $file, $line));
return true;
}
throw new ErrorException($message, 0, $severity, $file, $line);
});
set_exception_handler(function (Throwable $e): void {
error_log(sprintf('[%s] %s in %s:%d', $e::class, $e->getMessage(), $e->getFile(), $e->getLine()));
http_response_code(500);
echo 'Es ist ein Fehler aufgetreten.';
});
register_shutdown_function(function (): void {
$error = error_get_last();
if ($error !== null && in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR], true)) {
error_log('[fatal] ' . $error['message']);
}
});
Seit PHP 8.5 kannst du mit get_error_handler() und get_exception_handler() abfragen, welcher Handler gerade aktiv ist. Bisher ging das nur über den Umweg, einen Handler zu setzen und sofort wieder zurückzusetzen. Praktisch, wenn Bibliotheken, Tests und Framework sich gegenseitig den Handler überschreiben.
Code:
$current = get_error_handler();
if ($current === null) {
// Kein eigener Handler aktiv, PHP Standardverhalten greift
}
Monolog, Sentry und Grafana: vom Log zum Alarm
In Symfony übernimmt Monolog das Logging über den PSR 3 Standard. Fehler, die PHP selbst meldet, landen dort ebenfalls, weil der Symfony ErrorHandler sie einsammelt. Ein bewährtes Muster ist der fingers_crossed Handler: Er puffert alle Einträge eines Requests und schreibt sie erst, wenn ein Error auftritt. Dann bekommst du den kompletten Kontext statt einer einsamen Zeile.
Code:
# config/packages/prod/monolog.yaml
monolog:
handlers:
main:
type: fingers_crossed
action_level: error
handler: nested
excluded_http_codes: [404, 405]
buffer_size: 50
nested:
type: stream
path: php://stderr
level: debug
formatter: monolog.formatter.json
deprecation:
type: stream
channels: [deprecation]
path: '%kernel.logs_dir%/deprecations.log'
Auf das Log setzen wir zwei Werkzeuge. Sentry gruppiert gleiche Fehler, zeigt Stack Trace, Release und betroffene Nutzer und schlägt Alarm, wenn nach einem Deployment etwas Neues auftaucht. Grafana zeigt die Kurve dazu: Steigt die Zahl der Errors pro Minute, sieht das Team es, bevor das Support Postfach voll ist.
Das Error Log selbst bleibt trotzdem wichtig. Es ist die Quelle, die auch dann noch schreibt, wenn der externe Dienst nicht erreichbar ist.
Aktuelle Entwicklungen: PHP 8.4, 8.5 und 8.6
Rund um Fehler und Logs hat sich in den letzten PHP Versionen mehr getan als in den Jahren davor. Die wichtigste Neuerung kam mit PHP 8.5: Fatal Errors haben jetzt einen Stack Trace.
Früher stand bei einem Speicher oder Zeitlimit nur eine Zeile im Log. Datei und Zeile, aber kein Weg dorthin. Die neue Direktive fatal_error_backtraces ist standardmäßig aktiv und hängt die komplette Aufrufkette an, so wie du es von Exceptions kennst. Parameter mit #[\SensitiveParameter] bleiben dabei verborgen, zend.exception_ignore_args wird ebenfalls beachtet.
Code:
Fatal error: Allowed memory size of 134217728 bytes exhausted in /app/src/Export/CsvExport.php on line 42
Stack trace:
#0 /app/src/Export/CsvExport.php(42): str_repeat('A', 268435456)
#1 /app/src/Controller/ExportController.php(18): App\Export\CsvExport->build()
#2 {main}
Achtung bei Tools, die Log Zeilen parsen: Fatal Errors sind jetzt mehrzeilig. Alerting Regeln und Log Parser solltest du nach dem Upgrade einmal prüfen.
PHP 8.6 geht beim Thema Streams weiter. Das RFC Stream Error Handling Improvements von Jakub Zelenka ist angenommen und umgesetzt. Datei und Netzwerk Funktionen wie fopen() können damit über einen Stream Context Exceptions werfen oder Fehler strukturiert speichern. Statt Warning Texte im Log zu parsen, bekommst du typisierte Fehlercodes wie StreamErrorCode::NotFound oder PermissionDenied. Das Standardverhalten bleibt bewusst gleich, damit bestehende Bibliotheken nicht brechen.
Code:
$context = stream_context_create([
'stream' => [
'error_mode' => StreamErrorMode::Exception,
],
]);
try {
$handle = fopen('/data/import.csv', 'r', false, $context);
} catch (StreamException $e) {
$first = array_first($e->getErrors());
error_log('Import fehlgeschlagen: ' . $first?->code->name);
}
Neue Fehler Features nach PHP Version
Use Cases: Was das Error Log im Alltag leistet
Das Error Log ist mehr als ein Ort für Panik nach dem Deployment. Gut eingerichtet, beantwortet es Fragen, die sonst niemand beantworten kann.
Deployment absichern. Nach jedem Release vergleichst du die Fehlerrate mit der Stunde davor. Taucht ein neuer Fehler auf, ist der Zusammenhang sofort klar. Mit PHP Deployer lässt sich dieser Check als letzter Schritt einbauen.
PHP Upgrade vorbereiten. Ein paar Tage Deprecation Log auf Production zeigen dir genau die Stellen, die im nächsten Major Release brechen. Diese Liste geht an Rector und PHPCompatibility. Einen Überblick über die Änderungen gibt unser PHP 8 Versionen Vergleich.
Performance Probleme finden. Meldungen zu Zeitlimit und Speicher zeigen dir, welcher Export oder welcher Import zu schwer ist. Mit dem Stack Trace aus PHP 8.5 weißt du, wo du mit SPX oder einem Flame Graph ansetzt.
Tests im CI schärfen. Ein leeres Error Log ist ein Qualitätskriterium. Nach einem Cypress Lauf prüft die Pipeline, ob im Log neue Warnings stehen. Ist es nicht leer, schlägt der Build fehl, auch wenn jeder Test grün war. Für PHPUnit erledigen das die Optionen failOnWarning und failOnDeprecation.
Code:
# Nach dem E2E Lauf in der Pipeline
if [ -s var/log/php_error.log ]; then
echo "PHP Error Log ist nicht leer:"
cat var/log/php_error.log
exit 1
fi
Legacy Code verstehen. Bevor du alten Code anfasst, zeigt das Log, welche Teile wirklich laufen und wo sie scheitern. Zusammen mit Characterization Tests entsteht so ein Bild vom echten Verhalten.
Sicherheit überwachen. Häufen sich Warnings zu ungültigen Parametern oder fehlenden Dateien, steckt manchmal ein Scan dahinter. Das Log ergänzt hier die Prüfungen aus den OWASP Top 10.
PHP Error Log und KI Coding Agents
Ein Coding Agent ist nur so gut wie der Kontext, den er bekommt. Das Error Log ist dabei einer der wertvollsten Kontexte überhaupt: Es beschreibt nicht, was der Code tun soll, sondern was er wirklich getan hat.
In Symfony Projekten verbindet Symfony AI Mate Agents mit der laufenden Anwendung. Die Monolog Extension bringt Werkzeuge mit, um Logs zu durchsuchen, nach Level oder Kanal zu filtern und die letzten Einträge zu lesen. Statt per grep durch Dateien zu wühlen, fragt der Agent gezielt nach den Errors der letzten Minuten. Johannes Wachter hat Mate bei uns im NCA Stream vorgestellt.
Wir arbeiten dafür mit OpenCode und Open Weight Modellen. Wichtig ist die Umgebung: Coding Modelle lesen Logs aus der lokalen Entwicklung mit anonymisierten Testdaten, nie aus Production. Ein Production Log enthält schnell Mail Adressen, IDs oder Request Daten. Mate selbst ist ausdrücklich ein Werkzeug für die Entwicklung.
Der Ablauf, der sich bewährt hat:
- Fehler lokal reproduzieren, bis er im Log steht.
- Der Agent liest Eintrag und Stack Trace und schlägt eine Ursache vor.
- Zuerst entsteht ein Test, der den Fehler zeigt, dann der Fix.
- PHPStan und die Testsuite prüfen das Ergebnis, bevor ein Mensch es reviewt.
Monolog sends your logs to files, sockets, inboxes, databases and various web services.
Die NCA Erfahrung mit Fehlern in Production
Wenn ein Team zu uns kommt, schauen wir oft zuerst ins Error Log. Es erzählt in wenigen Minuten, wie es um ein Projekt steht: Wie viele Warnings laufen seit Jahren mit? Welche Deprecations blockieren das nächste Upgrade? Gibt es Fatal Errors, die niemand bemerkt hat? Die Antworten sind ehrlicher als jede Dokumentation.
Danach folgt immer dieselbe Reihenfolge. Erst kommen Quality Gates: PHPStan für statische Analyse, PHPUnit und Functional Tests für das Verhalten, Cypress für die Oberfläche. Dann räumen wir auf, mit Rector für automatische Upgrades und Composer Audit für unsichere Pakete. Wer die Ursachen verstehen will, misst mit Xdebug und SPX. Bei großem Altbestand empfehlen wir den Weg über ein paralleles neues Projekt mit dem Strangler Fig Pattern, statt ewig im Legacy weiterzuflicken. Lokal läuft das alles in DDEV mit anonymisierten Daten.
Erreichen Sie unsere PHP Consultant Spezialisten
Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.
Häufige Fragen zum PHP Error Log
Die wichtigsten Antworten rund um Einrichtung, Fundort und Auswertung des PHP Error Logs, kurz und direkt.
Wie aktiviere ich das PHP Error Log 2026?
Du setzt in der php.ini log_errors = On und error_log auf einen absoluten Pfad, auf den PHP schreiben darf. Dazu kommen error_reporting = E_ALL und für Production display_errors = Off. Nach einem Neustart von PHP FPM oder dem Webserver greift die Konfiguration. Mit php --ini prüfst du, welche php.ini wirklich geladen ist, denn CLI und Webserver nutzen oft verschiedene Dateien.
Wo finde ich das PHP Error Log 2026?
Den Pfad verraten php -i oder ini_get('error_log'). Ist kein Pfad gesetzt, schreibt PHP FPM in das Log des Pools, Apache mit mod_php in sein eigenes Error Log und die CLI auf stderr. In Containern und mit FrankenPHP landen Fehler meist in stdout und stderr. Seit PHP 8.5 zeigt php --ini=diff alle Werte, die vom Standard abweichen.
Was ändert sich 2026 mit PHP 8.5 am Error Log?
Die wichtigste Neuerung sind Stack Traces für Fatal Errors. Die Direktive fatal_error_backtraces ist standardmäßig aktiv und hängt die komplette Aufrufkette an Meldungen wie Speicher oder Zeitlimit an. Sensible Parameter bleiben dabei verborgen. Dazu kommen get_error_handler(), get_exception_handler() und php --ini=diff. Log Parser solltest du prüfen, weil Fatal Errors jetzt mehrzeilig sind.
Was bringt PHP 8.6 im Jahr 2026 für die Fehlerbehandlung?
PHP 8.6 führt strukturiertes Error Handling für Streams ein. Über einen Stream Context lassen sich fopen() und verwandte Funktionen so einstellen, dass sie Exceptions werfen oder Fehler still speichern. Statt Warning Texte zu parsen, bekommst du typisierte Codes über das Enum StreamErrorCode. Das Standardverhalten bleibt gleich, bestehender Code läuft also weiter wie bisher.
Welche Error Log Einstellungen sind 2026 für Production empfohlen?
Bewährt haben sich error_reporting = E_ALL, display_errors = Off, log_errors = On und ein absoluter error_log Pfad mit Log Rotation. zend.exception_ignore_args = On hält Argumente aus Stack Traces heraus. Fatal Error Backtraces bleiben aktiv, landen aber nur im Log. Ergänzend schickt Monolog Errors strukturiert an Sentry, und Grafana zeigt die Fehlerrate über die Zeit.
Warum sollte display_errors in Production aus sein?
Fehlermeldungen verraten Dateipfade, Datenbanknamen, SQL Abfragen und manchmal Zugangsdaten. Diese Informationen helfen Angreifern, die Anwendung gezielt anzugreifen. Außerdem zerstört eine Fehlermeldung mitten im HTML das Layout und verunsichert Besucher. Besser ist eine neutrale Fehlerseite mit Referenz ID. Die Details stehen im Error Log, wo nur das Team sie sieht.
Warum steht ein Fehler nicht im Error Log?
Häufige Ursachen: log_errors ist aus, der PHP Prozess darf nicht in die Datei schreiben, die CLI nutzt eine andere php.ini, oder ein eigener Error Handler gibt true zurück und schluckt den Fehler. Auch der @ Operator unterdrückt Meldungen. Prüfe mit php -i den aktiven Pfad und teste mit trigger_error und E_USER_WARNING, ob überhaupt etwas ankommt.
Was ist der Unterschied zwischen error_log() und dem Error Log?
Das Error Log ist das Ziel, in das PHP selbst Fehler schreibt. Die Funktion error_log() ist ein Weg, eigene Meldungen dort hineinzuschreiben, oder per Parameter in eine andere Datei. Für größere Anwendungen reicht error_log() selten. Ein Logger nach PSR 3 wie Monolog bietet Level, Kanäle, Kontext Daten und Handler für verschiedene Ziele.
Wie verhindere ich, dass Passwörter im Error Log landen?
Markiere sensible Parameter in Funktionssignaturen mit dem Attribut #[\SensitiveParameter]. PHP ersetzt ihren Wert in Stack Traces dann durch einen Platzhalter. Zusätzlich sorgt zend.exception_ignore_args = On dafür, dass Argumente gar nicht erst in Traces auftauchen. Bei eigenen Log Meldungen gilt: keine Request Bodies, Tokens oder vollständigen Nutzerdaten loggen.
Wie groß darf ein PHP Error Log werden?
Ohne Rotation wächst es, bis die Festplatte voll ist, und dann schreibt PHP gar nichts mehr. Richte logrotate ein, etwa täglich mit Komprimierung und einer festen Anzahl alter Dateien. Wichtiger als die Größe ist der Inhalt: Tausende gleiche Warnings sind ein Zeichen für Bugs, die behoben gehören, nicht für zu wenig Speicherplatz.
Sollte ich Deprecations in Production loggen?
Ja. Deprecations zeigen genau die Stellen, die mit dem nächsten Major Release brechen. Loggst du sie in einem eigenen Kanal, stören sie den Alarm für echte Fehler nicht. Vor einem Upgrade wertest du diesen Kanal aus und gibst die Liste an Rector oder PHPCompatibility weiter. So wird das Upgrade planbar statt überraschend.
Was mache ich mit E_STRICT in alten Konfigurationen?
Entfernen. E_STRICT wird seit PHP 8.0 nicht mehr ausgelöst, die Konstante ist seit PHP 8.4 deprecated und soll mit PHP 9 verschwinden. Ein error_reporting mit E_ALL | E_STRICT erzeugt heute selbst eine Deprecation. E_ALL deckt alles ab, was du brauchst. Rector und PHPCompatibility finden solche Stellen automatisch im Code.
Können KI Agents das PHP Error Log auswerten?
Ja, und das funktioniert gut, weil das Log beschreibt, was wirklich passiert ist. In Symfony Projekten gibt Symfony AI Mate Coding Agents Werkzeuge, um Monolog Logs zu durchsuchen und nach Level oder Kanal zu filtern. Wir lassen Agents dabei Logs aus der lokalen Entwicklung mit anonymisierten Testdaten lesen. So bleibt der Datenschutz gewahrt und der Fehler trotzdem nachvollziehbar.
Der Übersetzer zwischen Altsystem und neuem Domänenmodell. So verhindert ihr, dass Legacy Begriffe in den frischen Code sickern.
Der Abstract Syntax Tree ist die Baumdarstellung von PHP Quellcode. Tools wie Rector, PHPStan und PHP Parser nutzen den AST für Analyse und Refactoring.
Entdecken Sie, wie BackstopJS visuelle Regressionstests automatisiert und Ihre Webanwendungen vor unerwünschten Änderungen schützt.
Ein Modell gilt nur innerhalb seiner Grenze. So schneidet ihr Bounded Contexts sauber und haltet sie im PHP Alltag stabil.
PHP Callgraph erstellen mit Xdebug, gprof2dot und Graphviz dot. So visualisieren Entwickler Funktionsaufrufe, finden Performance Engpässe und optimieren Symfony Projekte gezielt.
Tests, die nicht prüfen was der Code tun soll, sondern festhalten was er heute tut. Das Sicherheitsnetz für Legacy Code ohne Testabdeckung.
