Comment exécuter des tests avec fastlane scan sur un Mac distant ? Guide 2026

Apple indique que l’exécution des tests avec Xcode peut produire un paquet de résultats .xcresult, exploitable pour examiner les essais après leur lancement (documentation Apple sur l’exécution des tests et l’interprétation des résultats). Symptôme : une commande démarre sur le Mac distant, mais cela ne prouve ni que le bon schéma a été testé ni que les résultats sont récupérables. Solution la plus rapide : validez d’abord un schéma et une destination de simulateur réellement disponibles, puis vérifiez les journaux et le paquet de résultats avant d’intégrer le flux à la CI. fastlane scan orchestre l’appel ; il ne remplace ni le Mac, ni Xcode, ni une validation sur appareil physique.

Ce guide s’adresse aux développeurs iOS qui veulent comparer l’exécution à distance avec leurs résultats locaux.
Il concerne aussi les ingénieurs CI chargés de conserver les traces d’échec et les équipes qui évaluent un Mac distant pour des tests réguliers.

Avant le premier lancement : vérifier le socle du Mac distant

Le point décisif n’est pas que fastlane soit installé, mais que le Mac puisse exécuter le projet dans les conditions attendues. scan, également appelé par l’action run_tests, lance les tests iOS à partir des outils Apple présents dans l’environnement. La documentation fastlane sur les tests iOS décrit ce rôle et son usage dans un flux de test ; le référentiel des outils de ligne de commande Xcode précise les commandes disponibles côté Xcode.

Avant toute commande de test, relevez les éléments qui influencent réellement la reproductibilité : chemin du projet ou de l’espace de travail, schéma partagé, cibles de test, version de Xcode sélectionnée, dépendances et gestion de Ruby. Ces vérifications évitent de confondre une différence d’environnement avec une régression du code.

Point de contrôle	Vérification sur le Mac distant	Risque si le contrôle est omis
Projet	Le fichier de projet ou d’espace de travail attendu existe au chemin utilisé par la tâche.	La commande vise un autre dépôt, une ancienne copie ou aucun projet.
Schéma	Le schéma de test est partagé et sélectionnable par les outils de ligne de commande.	Le projet s’ouvre dans l’interface graphique, mais la tâche automatisée ne trouve pas son point d’entrée.
Xcode	La version sélectionnée correspond à celle attendue par le projet et ses dépendances.	La compilation ou la résolution des dépendances diverge du poste de développement.
Ruby et fastlane	La méthode de gestion du projet et son fichier de verrouillage sont utilisés de façon cohérente.	Une installation globale ou une mise à jour implicite change le comportement du lane.
Simulateur	La destination déclarée existe dans la liste réellement disponible sur ce Mac.	La tâche échoue avant le lancement des tests, même si le schéma est correct.

La question « quelles vérifications effectuer avant de lancer fastlane scan à distance ? » se résout donc par une comparaison entre le projet et l’environnement effectif, et non par une liste universelle de versions. Nous ne fixons pas ici de compatibilité minimale : elle dépend du projet, de sa configuration et des versions effectivement choisies. Consignez celles-ci dans les fichiers du dépôt ou dans la documentation de l’équipe, puis vérifiez le résultat de la sélection Xcode et l’inventaire des simulateurs sur le nœud concerné.

Pour Ruby et fastlane, privilégiez la méthode de gestion déjà adoptée par le dépôt. Si le projet possède un fichier de verrouillage des dépendances, utilisez-le au lieu de réinstaller des versions différentes à chaque session. Une installation réussie ne garantit pas que le lancement de scan utilise le même exécutable que celui prévu par le projet ; vérifiez donc le chemin des outils et la commande réellement appelée dans les journaux.

Un accès SSH fonctionnel ne confirme pas que l’environnement graphique, Xcode et les simulateurs sont prêts. Avant de diagnostiquer fastlane, vérifiez séparément les outils de ligne de commande et les destinations visibles par le Mac distant.

Configurer l’entrée de test dans le projet

Une fois le socle vérifié, placez l’appel dans un lane du Fastfile. Cette configuration rend la commande réutilisable, facilite la revue du changement et évite de disperser des options différentes entre plusieurs scripts. La documentation de l’action run_tests détaille les paramètres de lancement, notamment ceux liés au schéma, à la destination, au plan de test et aux résultats.

Dans l’exemple ci-dessous, chaque valeur entre chevrons est un emplacement à remplacer par un élément réellement présent dans le projet ou sur le Mac distant. Les noms ne désignent pas une configuration matérielle particulière.

lane :tests_ios do
  run_tests(
    project: "<CHEMIN_PROJET>",
    scheme: "<SCHEMA_PARTAGE>",
    device: "<SIMULATEUR_DISPONIBLE>",
    testplan: "<PLAN_DE_TEST>",
    result_bundle: true,
    result_bundle_path: "<CHEMIN_RESULTAT>/tests.xcresult"
  )
end

Le paramètre de schéma doit correspondre au schéma partagé du projet. Le plan de test est à renseigner seulement si le dépôt en utilise un ; la documentation Apple explique comment les plans organisent les tests et leurs configurations dans les plans de test Xcode. Quant à la destination, elle doit être vérifiée sur le nœud : ne copiez pas le nom d’un simulateur vu sur un autre poste sans contrôler qu’il figure dans l’inventaire local.

Paramètre	Ce qu’il choisit	Vérification avant de l’enregistrer
`scheme`	Le schéma qui expose la construction et les tests à exécuter.	Confirmer son nom exact et son partage dans le projet.
`testplan`	Le plan de test à employer lorsque le projet en utilise un.	Vérifier son nom dans le projet ; ne pas en inventer un pour un dépôt qui n’en possède pas.
`device`	La destination de test, ici un simulateur sélectionné.	Comparer la valeur à la liste des simulateurs disponibles sur ce Mac.
`result_bundle_path`	Le chemin de sortie choisi pour le paquet de résultats.	S’assurer que le répertoire existe ou que le flux prévoit de le créer et de le récupérer.

Si le projet repose sur un espace de travail plutôt que sur un fichier de projet, adaptez le point d’entrée en conséquence ; ne laissez pas en même temps des paramètres contradictoires dans le lane et la configuration locale. La commande doit être reproductible depuis le répertoire et avec l’environnement que la tâche CI utilisera. Il est également utile de garder les options propres au projet dans le dépôt, plutôt que de dépendre d’une modification manuelle sur le nœud.

Pour l’exécution, la commande de base peut prendre cette forme :

bundle exec fastlane tests_ios

Utilisez l’invocation correspondant à la gestion des dépendances du projet ; si fastlane est lancé autrement dans le dépôt, ne changez pas de méthode sans vérifier ce que cela modifie. Le but de l’essai n’est pas seulement d’obtenir une commande sans erreur de syntaxe : il faut démontrer que le bon schéma, la bonne destination et les bons tests ont été sélectionnés.

Quand fastlane scan ne trouve pas le simulateur, contrôler d’abord la destination

Un simulateur absent de la liste des destinations ne se corrige pas en répétant la même commande. Commencez par comparer la valeur du paramètre device avec l’inventaire disponible sur le Mac qui exécute le lane. La commande xcrun simctl list devices available permet d’inspecter les appareils simulés disponibles ; la référence Apple des outils de ligne de commande Xcode donne le cadre des outils utilisés pour piloter Xcode.

Si la destination manque, séparez les hypothèses au lieu de modifier plusieurs composants à la fois : Xcode sélectionné, simulateurs installés ou disponibles, orthographe de la destination, puis réglages du projet. Une différence entre l’environnement local et le Mac distant est fréquente lorsqu’un développeur a configuré un simulateur qui n’existe pas sur le nœud. Le nom exact doit donc être vérifié sur le système d’exécution, et non déduit d’une capture d’écran ou d’une ancienne configuration.

Un premier essai réduit également le coût du diagnostic. Lancez le lane avec le schéma et la cible de test les plus simples qui représentent le projet, puis élargissez aux tests complets seulement lorsque la construction, le démarrage du simulateur et l’exécution sont confirmés. Si le projet utilise plusieurs plans ou configurations, introduisez-les séparément : autrement, un échec peut venir d’une combinaison de paramètres plutôt que du test lui-même.

Première exécution : distinguer résolution, compilation et assertions

À la première exécution, recueillez des preuves à chaque étape. Une commande qui renvoie un état d’échec ne dit pas à elle seule si le problème vient de la résolution des dépendances, de la construction, du démarrage du simulateur ou d’une assertion. Conservez la sortie complète de fastlane, repérez la phase qui échoue, puis comparez-la au rapport produit par Xcode.

La progression suivante limite les diagnostics ambigus :

Vérifiez que la tâche se place dans le bon dépôt et charge la méthode de gestion Ruby du projet.
Lancez le lane avec le schéma partagé, sans ajouter des options de test non nécessaires.
Confirmez dans la sortie que la destination demandée correspond au simulateur attendu.
Repérez le démarrage de la construction et l’exécution effective des tests, plutôt que de vous limiter au message indiquant que fastlane a commencé.
Examinez les erreurs de test et les résultats Xcode pour distinguer les assertions en échec des erreurs d’environnement.
Après réussite de cet essai, élargissez la couverture au plan ou à l’ensemble de tests prévu par l’équipe.

Ce séquencement est particulièrement utile pour les tests d’interface iOS, qui dépendent du démarrage de l’application et de l’état du simulateur. Une erreur au lancement n’est pas équivalente à une assertion qui échoue pendant le test. À l’inverse, un test marqué comme réussi ne prouve pas que le flux a couvert tous les appareils, toutes les configurations ou les comportements qui dépendent d’un appareil physique.

Le guide fastlane sur l’intégration continue illustre l’intégration de fastlane à une chaîne CI. Même si l’équipe utilise un autre orchestrateur, les besoins restent semblables : lancer une commande reproductible, remonter son état de sortie, conserver les journaux utiles et rendre les résultats accessibles après le travail. Ne transformez pas un essai interactif concluant en déploiement général sans reproduire ces conditions dans la tâche automatisée.

Conserver les résultats même en cas d’échec

La configuration du chemin de résultat ne suffit pas si le processus CI supprime les fichiers lorsque la commande échoue. Prévoyez deux opérations distinctes : faire produire les résultats par l’exécution, puis organiser leur conservation et leur récupération dans la tâche qui pilote le Mac. Les paramètres de résultat de run_tests sont décrits dans la documentation officielle de l’action, tandis qu’Apple explique comment interpréter les tests et les résultats dans sa documentation sur l’exécution et l’analyse des résultats Xcode.

Élément à conserver	Pourquoi le garder	Contrôle après un échec
Sortie de la tâche	Elle identifie la phase et le message d’erreur remontés par fastlane.	Vérifier que le journal est encore accessible après la fin de la tâche.
Journaux de construction	Ils aident à séparer les erreurs de compilation des résultats de test.	Confirmer qu’ils correspondent à la même exécution et au même dépôt.
Paquet `.xcresult`	Il permet de consulter les informations de résultat produites par Xcode.	Vérifier l’existence du paquet et la possibilité de le récupérer hors du nœud.
État final de la commande	Il indique si la tâche a échoué ou s’est terminée sans erreur remontée.	S’assurer que l’étape de conservation s’exécute également lorsque les tests échouent.

L’équipe doit définir où ces éléments sont stockés, combien de temps ils restent accessibles et qui peut les télécharger ; ces choix dépendent de sa propre chaîne de traitement. Ne supposez pas qu’un paquet créé sur le Mac sera automatiquement copié vers un espace accessible aux développeurs. Testez la récupération avec une exécution en échec volontaire ou reproductible, puis vérifiez que le journal et le paquet restent disponibles après la fin de la tâche.

Un rapport lisible peut compléter le paquet de résultats, mais il ne le remplace pas forcément : le choix des formats et de leur publication doit être cohérent avec les outils de l’équipe. Évitez aussi d’écrire les résultats dans un répertoire temporaire nettoyé avant leur transfert. Le contrôle utile est concret : un membre de l’équipe doit pouvoir retrouver l’exécution concernée, identifier le test en échec et ouvrir les données correspondantes sans se reconnecter au nœud.

Évaluer le passage de l’essai à la CI

La décision ne se réduit pas à « la commande fonctionne ». Il faut vérifier le même changement de code dans des conditions reproductibles, puis mesurer si l’équipe récupère suffisamment d’éléments pour traiter un échec. Le tableau suivant est une grille de décision qualitative : ses appréciations portent sur l’adéquation du mode de travail, et non sur une mesure de performance ou une garantie de résultat.

Option	Pertinence pour des essais réguliers	Points à vérifier	Appréciation
Mac de développement local	Adapté si l’équipe maîtrise déjà l’environnement et peut réserver la machine aux tests.	Disponibilité pendant les tâches, cohérence de Xcode et collecte des résultats.	Favorable si les ressources sont disponibles.
Mac distant accessible à la demande	Utile pour valider le projet sans acheter ou maintenir immédiatement une machine dédiée.	Accès aux outils attendus, persistance du dépôt, continuité du travail et transfert des fichiers.	Conditionnel à un essai réussi sur le vrai projet.
Nœud Mac durable intégré à la CI	Approprié lorsque les tests doivent s’exécuter régulièrement et laisser des traces exploitables.	Surveillance, mise à jour de l’environnement, récupération des résultats et reprise après interruption.	Favorable si l’équipe peut maintenir le nœud.
Simulateur seulement	Adapté aux vérifications automatisées compatibles avec un environnement simulé.	Comportements dépendant du matériel, des capteurs ou de conditions physiques.	Insuffisant pour une validation complète sur appareil.

Une fois les essais à distance reproductibles, exécutez de nouveau le même changement et vérifiez les quatre éléments suivants : sélection correcte du schéma, exécution observable, état d’échec transmis à l’orchestrateur et récupération des résultats après la tâche. Si l’un de ces contrôles échoue, poursuivez l’essai ou corrigez l’intégration avant de déclarer le nœud prêt pour une CI régulière.

Les tests sur simulateur ne sont pas une validation sur appareil physique. Apple distingue les appareils simulés des appareils physiques dans sa documentation sur l’exécution d’une app sur un simulateur ou un appareil. Le simulateur est utile pour automatiser des scénarios pris en charge par le projet, mais il ne reproduit pas toutes les conditions matérielles. Si la couverture requiert une vérification propre à un appareil réel, prévoyez une étape de validation dédiée ; ne présentez pas un succès de fastlane scan comme une recette de validation matérielle.

Pour un Mac distant utilisé uniquement pendant les essais et le diagnostic, une formule à la demande peut éviter d’acheter une machine avant d’avoir confirmé le besoin. Pour une charge continue, des interfaces physiques nécessaires aux tests ou un environnement qui doit rester durablement sous le contrôle de l’équipe, l’achat et la maintenance d’un Mac peuvent être plus adaptés. Nous recommandons de comparer les deux options après l’essai du projet, et non sur la seule promesse d’une commande compatible. Vous pouvez consulter les solutions de location de Mac distant pour vérifier les modalités disponibles, puis la présentation de VNCMac si vous devez examiner le fonctionnement du service avant de choisir.

En pratique, fastlane scan convient à l’orchestration des tests, mais la décision de mise en production doit reposer sur l’environnement réel, la destination réellement disponible et la conservation vérifiée des résultats. Si un schéma représentatif passe sur le Mac distant et que l’équipe sait récupérer les traces d’échec, vous pouvez avancer vers l’intégration CI. Si les tests exigent un appareil physique ou si la récupération des résultats n’est pas maîtrisée, gardez l’essai à distance comme étape de validation et complétez le dispositif avant le déploiement.