Reproduzierbare iOS-Medienimporttests mit simctl addmedia

Nachdem Nutzer ein Bild aus der Fotomediathek ausgewählt haben, muss die App möglicherweise dessen Ausrichtung auslesen, ein Vorschaubild erzeugen, das Original komprimieren und anschließend hochladen. Bei Videos kommen weitere Verzweigungen für Dauer, Codierung und Dateigröße hinzu. Ein einzelner manueller Test auf dem Entwicklungs-Mac belegt nicht, dass der nächste Build dieselben Eingaben weiterhin korrekt verarbeitet. Zuverlässiger ist es, die Mediendateien als Test-Fixtures in das Repository aufzunehmen, einen separaten Simulator auf einem Cloud-Mac zurückzusetzen und die Dateien anschließend mit simctl addmedia in die Fotomediathek zu importieren.

Zuerst die zu prüfenden Grenzen festlegen

Solche Tests sollten sich auf die Schnittstelle zwischen der App und der Systemfotomediathek konzentrieren, nicht auf die automatisierte Bedienung der Fotos-App. Mindestens die folgenden vier Abläufe sollten abgedeckt werden:

1. Die App findet die erwartete Anzahl an Bildern und Videos.
2. Nach der Rückgabe durch die Auswahl stimmen Dateityp, Pixelabmessungen und Videodauer mit den Erwartungen überein.
3. Komprimierungs- oder Upload-Aufgaben verwenden die Originalressource und nicht versehentlich ein Vorschaubild.
4. Nicht unterstützte Formate, sehr große Dateien und geänderte Berechtigungen führen in klar definierte Fehlerpfade.

simctl addmedia eignet sich dazu, die Lese- und Verarbeitungskette im Simulator zu prüfen. Es ersetzt jedoch keine Tests der Kameraaufnahme, gerätespezifischer Codierungen oder realer Speicherbelastung. Werden diese Grenzen in der Testbeschreibung dokumentiert, lassen sich Einschränkungen des Simulators bei einem Fehlschlag besser von tatsächlichen Produktfehlern unterscheiden.

Ziel eines Regressionstests ist nicht, möglichst viele Dateien einzuspielen. Jede Datei sollte vielmehr für ein eindeutig benennbares, reproduzierbares und diagnostizierbares Verhalten stehen.

Kleine und stabile Medien-Fixtures vorbereiten

Legen Sie im Repository das Verzeichnis Tests/Fixtures/Media an und speichern Sie dort nur die für die Tests erforderlichen Minimaldateien. Die Dateinamen sollten ihren vorgesehenen Zweck erkennen lassen; automatisch von Kameras erzeugte Namen sind ungeeignet.

Speichern Sie außerdem eine SHA-256-Prüfsummenliste, damit Bildbearbeitungsprogramme die Fixtures nicht unbemerkt überschreiben können:

cd Tests/Fixtures/Media
shasum -a 256 portrait.jpg transparent.png short.mov > SHA256SUMS
shasum -a 256 -c SHA256SUMS

Die Fixtures sollten während des Testlaufs nicht neu codiert werden. Encoder verschiedener Systemversionen können unterschiedliche Metadaten schreiben. Dadurch wird aus einer Änderung des App-Verhaltens unbemerkt eine Änderung der Eingabedaten. Falls dynamisch erzeugte Dateien erforderlich sind, sollten das Generierungsskript, seine Parameter und die Prüfsumme der erzeugten Datei gemeinsam dokumentiert werden.

Simulator für jeden Auftrag isolieren

Ein gemeinsam genutzter, dauerhaft laufender Simulator hinterlässt Fotoressourcen, Berechtigungseinträge und Hintergrundprozesse. Als einfache Ausgangsbasis kann die Ausführungsschicht DEVICE_UDID übergeben. Zu Beginn des Auftrags wird der Simulator heruntergefahren, gelöscht und vollständig gestartet:

set -euo pipefail

: "${DEVICE_UDID:?DEVICE_UDID is required}"
: "${BUNDLE_ID:?BUNDLE_ID is required}"

xcrun simctl shutdown "$DEVICE_UDID" 2>/dev/null || true
xcrun simctl erase "$DEVICE_UDID"
xcrun simctl boot "$DEVICE_UDID"
xcrun simctl bootstatus "$DEVICE_UDID" -b

xcrun simctl privacy "$DEVICE_UDID" reset photos "$BUNDLE_ID" || true
xcrun simctl privacy "$DEVICE_UDID" grant photos "$BUNDLE_ID"

Auch Simulatormodell und Systemversion müssen in der Auftragskonfiguration fest vorgegeben sein. Eine ungenaue Angabe wie name=iPhone, bei der Xcode selbst ein Gerät auswählt, reicht nicht aus. Parallel ausgeführte Aufträge müssen unterschiedliche UDIDs verwenden. Andernfalls kann ein Auftrag erase ausführen, während ein anderer gerade seine Tests auf demselben Simulator ausführt.

Berechtigungstests sollten in zwei Gruppen aufgeteilt werden: Für den Hauptablauf wird der Zugriff auf die Fotomediathek vorab gewährt, um die Medienverarbeitung zu prüfen. Der Ablauf mit verweigerter Berechtigung führt separat revoke aus und prüft ausschließlich den Hinweis der App sowie die angebotene Möglichkeit zur Wiederherstellung des Zugriffs. Ob ein Systemdialog erscheint, darf nicht über Erfolg oder Fehlschlag des Tests entscheiden.

Medien importieren und gezielte Tests ausführen

Prüfen Sie vor dem Import die Dateiendungen und Prüfsummen. Übergeben Sie anschließend alle unterstützten Dateien gemeinsam an addmedia:

FIXTURES="$PWD/Tests/Fixtures/Media"

shasum -a 256 -c "$FIXTURES/SHA256SUMS"

xcrun simctl addmedia "$DEVICE_UDID" \
  "$FIXTURES/portrait.jpg" \
  "$FIXTURES/transparent.png" \
  "$FIXTURES/short.mov"

xcodebuild test \
  -workspace Demo.xcworkspace \
  -scheme Demo \
  -destination "platform=iOS Simulator,id=$DEVICE_UDID" \
  -only-testing:MediaImportTests \
  -resultBundlePath "$PWD/Artifacts/MediaImport.xcresult"

Eine erfolgreiche Rückgabe von addmedia bedeutet lediglich, dass der Befehl die Dateien angenommen hat. Sie bestätigt nicht, dass die App bereits die richtigen Ressourcen sieht. Der Testcode sollte warten, bis die Abfrage der Fotomediathek die erwartete Anzahl erreicht, und dabei ein begrenztes Zeitlimit verwenden. Assertions sollten sich vorrangig auf Medientyp, Pixelabmessungen, Dauerbereich und fachliche Verarbeitungsergebnisse stützen. Die Anzeigereihenfolge in der Systemfotomediathek ist ungeeignet, weil Importzeitpunkt und Erstellungsdatum einer Ressource voneinander abweichen können.

Wenn die App Dateien hochlädt, lässt sich die Netzwerkschicht durch eine lokale Testimplementierung ersetzen, die den empfangenen MIME-Typ, die Byteanzahl und die Prüfsumme protokolliert. So kann bestätigt werden, dass tatsächlich die Originalressource gelesen wurde, ohne externe Netzwerkschwankungen in die Regressionsergebnisse einzubeziehen.

Fehlschläge nachvollziehbar dokumentieren

Bei einem fehlgeschlagenen Auftrag sollten mindestens drei Arten von Nachweisen erhalten bleiben: das xcresult, die Prüfsummen der Fixtures und die Geräteinformationen des aktuellen Laufs. Zusätzlich kann die Liste der derzeit verfügbaren Simulatoren ausgegeben werden. Inhalte aus Benutzerverzeichnissen, die nicht mit dem Problem zusammenhängen, sollten dagegen nicht erfasst werden.

Typische Fehldiagnosen und geeignete Maßnahmen sind:

• Mehr Ressourcen als erwartet: Der Simulator wurde vor dem Auftrag nicht gelöscht oder mehrere Aufträge haben dieselbe UDID verwendet.
• Der Test findet das Video gelegentlich nicht: Die Abfrage erfolgt unmittelbar nach dem Import, ohne auf die Aktualisierung der Fotomediathek zu warten.
• Breite und Höhe des Bildes sind vertauscht: Beim Auslesen der Pixelabmessungen ignoriert der Code die Ausrichtungsmetadaten.
• Lokal erfolgreich, in CI fehlgeschlagen: Der Test hängt von nicht eingecheckten Dateien, Standardberechtigungen oder einer ungenauen destination-Angabe ab.
• Die Upload-Prüfsumme ändert sich: Die App codiert die Ressource neu. Die Prüfsummen der Eingabedatei und des Upload-Inhalts sollten getrennt protokolliert werden.

Fahren Sie den Simulator am Ende des Auftrags herunter. Wurde das Gerät temporär für diesen Auftrag erstellt, sollte es direkt gelöscht werden. Auch dauerhaft vorgehaltene Geräte sollten vor dem nächsten Auftrag erneut mit erase zurückgesetzt werden, statt einzelne Inhalte aus der Fotomediathek zu entfernen. Die abschließende Prüfliste lässt sich auf folgende Punkte reduzieren: Die Fixture-Prüfsummen stimmen überein, die UDID wird exklusiv verwendet, die Systemversion ist festgelegt, der Berechtigungsstatus ist explizit gesetzt, auf die erwartete Importanzahl wird gewartet und das Ergebnis-Bundle wurde archiviert. Erst dann verfügen fehlgeschlagene Medienimporte über stabile Eingaben und einen später nachvollziehbaren Testzustand.

Häufig gestellte Fragen