Wie führt fastlane scan Tests auf einem Remote Mac aus? Leitfaden 2026

Vor dem ersten Lauf: Projekt- und Werkzeugkettenbasis

Prüfen Sie zunächst, ob das Remote-Arbeitsverzeichnis tatsächlich den Projektstand enthält, den Sie testen möchten. Ein vorhandenes Repository ohne korrekt geladene Unterprojekte, benötigte Konfigurationsdateien oder Testressourcen kann einen Fehler erzeugen, der zunächst wie ein Problem mit fastlane aussieht. Halten Sie fest, welcher Commit beziehungsweise Arbeitsstand geprüft wird, und verwenden Sie für den Vergleich lokal und remote denselben Stand.

Danach folgen die Projekt- und Xcode-Einstellungen:

• Workspace oder Projektdatei: Verwenden Sie den Einstiegspunkt, den das Projekt auch lokal für Tests nutzt. Verwechseln Sie nicht eine .xcodeproj-Datei mit einem benötigten Workspace.
• Scheme: Kontrollieren Sie, ob es auf dem Remote Mac verfügbar und für den Testlauf geeignet ist. Ein Scheme, das nur lokal oder in einer nicht eingecheckten Xcode-Konfiguration existiert, lässt sich auf dem Knoten nicht zuverlässig auswählen.
• Testziele und Testplan: Prüfen Sie, welche Unit- oder UI-Testziele zum Scheme gehören und ob ein Testplan ausgewählt werden muss. Apple beschreibt, wie Testpläne Tests organisieren und ihr Feedback strukturieren.
• Xcode-Auswahl: Stellen Sie fest, welche Xcode-Umgebung der Remote Mac für den Aufruf tatsächlich verwendet. Die installierte Version allein reicht als Nachweis nicht; entscheidend ist die vom Prozess aufgerufene Werkzeugkette.
• Ruby und fastlane: Halten Sie fest, wie Ihr Projekt Ruby und fastlane verwaltet. Nutzen Sie, sofern vorhanden, die bestehenden Projektdateien zur Versions- und Abhängigkeitsbindung, statt auf dem Knoten nebenbei eine abweichende globale Umgebung einzurichten.
• Abhängigkeiten und Berechtigungen: Klären Sie, ob Paketquellen erreichbar sind, ob das Projekt Zugriff auf private Abhängigkeiten benötigt und welche Zugangsdaten der Testlauf wirklich braucht.

Für macOS-Projekte mit Geheimnissen, Signiermaterial oder privaten Quellcode-Repositories ist die Trennung zwischen Testzugang und Administrationszugang besonders wichtig. Gewähren Sie dem Lane-Prozess nur die benötigten Rechte, und geben Sie Schlüssel oder Tokens nicht in ausführbaren Logs aus. Bei einem Teamknoten sollten außerdem Zuständigkeit für Zugangsdaten, Bereinigung nach dem Lauf und Zugriff auf Testergebnisse dokumentiert sein. Diese Punkte beeinflussen nicht nur Datenschutz und DSGVO-Konformität, sondern auch, ob sich ein fehlgeschlagener Lauf sicher wiederholen lässt.

Erstkonfiguration in einer wiederverwendbaren Lane

Legen Sie den Testaufruf in einer Lane ab, statt die Parameter nur als einmaligen Terminalbefehl zu verwenden. So können Entwickler und CI denselben Einstiegspunkt nutzen und Änderungen an Scheme, Testplan oder Ergebnisablage an einer nachvollziehbaren Stelle prüfen. Die folgende Skizze verwendet bewusst Platzhalter. Ersetzen Sie sie durch die Werte Ihres Projekts und einen Simulator, den der Remote Mac tatsächlich anbietet.

lane :remote_tests do
  run_tests(
    workspace: "<PFAD_ZUM_WORKSPACE>",
    scheme: "<SCHEME_NAME>",
    devices: ["<VERFÜGBARER_SIMULATOR>"],
    result_bundle_path: "<PFAD_ZUM_ERGEBNISBUNDLE>"
  )
end

Die konkrete Schreibweise und Verfügbarkeit einzelner Parameter müssen Sie mit der aktuellen Parameterdokumentation von run_tests und der vorhandenen Projektkonfiguration abgleichen. Verwenden Sie nicht ungeprüft Optionen aus einem älteren Beispiel: Die passende Konfiguration hängt unter anderem davon ab, ob das Projekt mit einem Workspace oder einer Projektdatei arbeitet und wie seine Testpläne eingerichtet sind.

Für einen kontrollierten Einstieg begrenzen Sie den ersten Lauf auf ein bekanntes Testziel, sofern die Projektstruktur diese Auswahl unterstützt. Erweitern Sie ihn erst, wenn der minimale Lauf den erwarteten Build- und Testergebnisweg durchlaufen hat. Ein zu früh gestarteter Volltest kann mehrere Fehlerarten gleichzeitig sichtbar machen, ohne ihre Ursache klarer einzugrenzen.

Die Lane muss außerdem nachvollziehbar festlegen, wo Ergebnisse und Logs abgelegt werden. Verwenden Sie Pfade, die für den Prozess auf dem Remote Mac erreichbar sind, und entscheiden Sie, wie die CI sie nach dem Lauf abholt. fastlane kann den Testaufruf in einer CI-Umgebung einbinden; die CI-Dokumentation von fastlane erläutert eine solche Integration. Sie ersetzt nicht die teaminterne Festlegung, wie Artefakte gespeichert, zugriffsgeschützt und aufbewahrt werden.

Ergebnisdateien sichern und CI-Ausgabe prüfen

Ein Testergebnis ist nur dann später verwertbar, wenn es nach dem Lauf noch erreichbar ist. xcodebuild kann ein Xcode-Testresultat in einem Ergebnisbundle ablegen; der konkrete Pfad und die Übergabe an die CI müssen in der Lane beziehungsweise im Workflow festgelegt werden. Die oben verlinkte Apple-Dokumentation zum Testlauf beschreibt den Zusammenhang zwischen Ausführung und Ergebnisdarstellung.

Wie die CI Ergebnisdateien nach einem Fehlschlag behält

Legen Sie den Ausgabepfad für das Ergebnisbundle vor dem Lauf fest und prüfen Sie, dass der CI-Ablauf die Datei auch dann als Artefakt behandelt, wenn der Testschritt fehlschlägt. Ein Workflow, der Artefakte ausschließlich nach erfolgreichem Job speichert, kann gerade die wichtigste Diagnoseinformation verlieren. Bewahren Sie zusätzlich die für die Fehlersuche nötigen Textlogs auf und begrenzen Sie ihren Inhalt, wenn dort Pfade, interne Projektdaten oder sensible Werte erscheinen könnten.

Das Ergebnisbundle ermöglicht die spätere Prüfung des Testzustands, ist aber nicht automatisch ein vollständiges Archiv der gesamten CI-Ausführung. Definieren Sie separat, wo Logs landen, wie Teammitglieder die Dateien abrufen und wie lange sie nach internen Datenschutz- und Aufbewahrungsregeln benötigt werden. Die tatsächliche Upload- und Downloadmethode ist eine Entscheidung Ihrer Pipeline; sie lässt sich nicht allein aus dem Vorhandensein von fastlane scan ableiten.

Bewerten Sie außerdem die Rückgabe nach einem Fehler: Ist der Knoten nach einem abgebrochenen Simulatorlauf erneut nutzbar? Sind temporäre Dateien und Prozesse entfernt oder eindeutig einem Lauf zugeordnet? Werden Zugriffsrechte für Ergebnisdateien so gesetzt, dass nur berechtigte Teammitglieder sie einsehen? Ohne diese Prüfungen kann eine funktionierende Test-Lane im geteilten Betrieb trotzdem schwer wartbar oder datenschutzrechtlich ungeeignet sein.

Abnahme vor dem CI/CD-Rollout

Vergleichen Sie vor der Freigabe dieselbe Projektversion lokal und auf dem Remote Mac, soweit Ihr lokaler Ablauf als Referenz geeignet ist. Stimmen Scheme, Testziele und erwartete Testergebnisse überein? Lassen sich Logs und Ergebnisbundle nach einem absichtlich fehlgeschlagenen Testlauf tatsächlich abrufen? Kann der Knoten nach dem Lauf erneut für einen Test verwendet werden? Diese Prüfpunkte beantworten mehr als ein einmaliges „Lane erfolgreich“-Signal.

Für die Entscheidung zwischen Weiterbetrieb und Nacharbeit eignet sich folgende Gegenüberstellung:

Die Abnahme sollte einen Fehlerfall einschließen, nicht nur den grünen Durchlauf. Lösen Sie dafür in einer kontrollierten Teständerung einen erwarteten Fehler aus und prüfen Sie, ob der Job mit einem passenden Status endet, die Artefakte erhalten bleiben und die verantwortliche Person die Ursache aus den Belegen eingrenzen kann. Entfernen Sie die Teständerung anschließend und bestätigen Sie, dass der normale Lauf wieder den erwarteten Zustand erreicht.

Nutzen Sie die Ergebnisse für eine klare Entscheidung: Bleiben Scheme, Simulatorziel oder Artefaktübergabe unklar, setzen Sie den Probelauf fort und korrigieren Sie zuerst diese Punkte. Sind Testlauf, Fehlerbelege und Wiederherstellung mit demselben Projektstand nachvollziehbar, kann die Lane in den regulären CI/CD-Ablauf übernommen werden. Wird echte Hardware benötigt, ergänzen Sie eine dafür geeignete Geräteprüfung, statt den Simulatorlauf als Ersatz auszugeben.

Für Teams ohne dauerhaft verfügbaren Mac ist ein Remote Mac eine mögliche Alternative zum sofortigen Hardwarekauf, sofern das Projekt und die erforderlichen Xcode-Werkzeuge dort tatsächlich laufen. Die Mietübersicht von VNCMac für Remote Macs kann als nächster Prüfpunkt dienen; für verteilte Teams sollte außerdem die passende Region anhand der eigenen Zugriffswege beurteilt werden, etwa über die Informationen zu Remote Macs in Japan. Prüfen Sie vor einer längerfristigen Entscheidung zunächst mit einem realen Scheme, ob Werkzeugkette, Zugriff und Ergebnisrückgabe in Ihrem Ablauf funktionieren. Wenn Sie dafür einen zeitlich begrenzten Testknoten benötigen, können Sie anschließend die Mietoptionen von VNCMac mit Selbstkauf und vorhandener CI-Infrastruktur vergleichen. Langfristige, dauerhaft ausgelastete Builds oder Anforderungen an physische Geräte können eine eigene Hardware- beziehungsweise Gerätefarm sinnvoller machen.