Xcode 27 : comment choisir l’interopérabilité entre Swift Testing et XCTest ? Guide 2026

Swift Testing et XCTest peuvent coexister dans un même projet et dans une même cible de tests. Le réglage d’interopérabilité détermine comment les problèmes liés à certains usages croisés sont traités. Il ne choisit pas un framework à la place de l’autre et ne convertit pas automatiquement les tests existants.

Apple présente XCTest comme un framework de test et documente les possibilités de test dans sa vue d’ensemble des tests Xcode. Pour votre décision, l’enjeu concret est plus étroit : que se passe-t-il lorsqu’un test écrit avec Swift Testing appelle une API d’assertion XCTest ?

Voici un cas minimal, à employer comme sonde de migration. Dans une fonction de test Swift Testing, vous pouvez provoquer un échec via une assertion XCTest, puis observer comment cet échec apparaît dans les résultats. L’objectif n’est pas de recommander cet assemblage comme style de test, mais de déterminer si votre configuration rend le problème visible et avec la gravité attendue. La documentation Apple sur Issue.record aide à distinguer l’enregistrement d’un problème de l’usage d’une assertion issue d’un autre framework.

Les deux frameworks peuvent-ils cohabiter dans la même cible de tests ? Oui. La coexistence n’implique pas que chaque test puisse mélanger librement leurs API sans conséquence : c’est précisément ce que le réglage d’interopérabilité aide à contrôler. Conservez les tests XCTest qui remplissent encore leur rôle, ajoutez Swift Testing là où il apporte une amélioration claire, puis validez les appels croisés avec un test témoin.

Une distinction utile pour l’équipe : une migration peut avancer sans que le framework historique soit immédiatement supprimé. Vous pouvez donc traiter séparément la structure du projet, le choix des API dans les nouveaux tests et la politique appliquée aux appels transversaux. Cela évite de transformer une question de gravité en chantier de réécriture.

Les quatre modes se distinguent par la façon dont ils traitent les problèmes associés à l’interopérabilité. Le choix doit traduire une politique d’équipe, pas servir à masquer un résultat gênant. La table résume les critères de décision ; pour la sémantique exacte dans votre version, appuyez-vous sur les définitions Apple et les notes de version de Xcode 27.

Faut-il choisir limited ou complete ? Pour une migration progressive, évaluez d’abord complete sur une copie représentative de la suite : il permet de vérifier les problèmes en conservant leur gravité. Gardez limited si vous avez une raison de maintenir le comportement de compatibilité d’un ancien plan, mais ne déduisez pas que ce réglage est le meilleur choix pour les nouveaux tests. Comparez les résultats, puis documentez pourquoi vous conservez ou modifiez le mode.

Ne confondez pas « message visible » et « échec du même niveau ». Pour chaque appel croisé, notez si le résultat est enregistré, quelle gravité lui est attribuée et si l’exécution continue. C’est cette observation, et non le seul nom du mode, qui vous permet de prévoir l’effet sur les développeurs et sur le pipeline.

N’utilisez pas none comme correctif permanent parce qu’un contrôle rend la CI rouge. Vous pourriez supprimer un signal utile sans résoudre l’appel à l’origine du problème. Si vous désactivez temporairement le traitement pour isoler une cause, consignez le motif, la cible concernée et la condition de retour.

Le mode strict mérite une décision explicite. Il convient lorsque la règle recherchée est connue et que les corrections sont prévues, pas lorsqu’une équipe n’a pas encore déterminé si les tests concernés sont obsolètes, intentionnels ou simplement mal configurés. Sans cette distinction, vous risquez de convertir une migration observable en blocage difficile à diagnostiquer.

Une mise à jour de Xcode ne garantit pas que tous les projets adoptent le même mode. Un projet créé récemment et un plan de test conservé depuis une ancienne configuration peuvent présenter des réglages différents. C’est pourquoi la version installée ne suffit pas pour expliquer un résultat : inspectez la configuration effective du plan qui exécute les tests.

Pourquoi un ancien plan reste-t-il en limited après une mise à niveau ? Parce que la version de l’outil et les paramètres enregistrés dans un plan de test sont deux éléments distincts. Ne concluez pas que la mise à niveau a uniformisé les réglages. Ouvrez le plan utilisé par la cible concernée, recherchez son option d’interopérabilité, puis confrontez sa valeur au résultat de l’exécution. La documentation d’Apple sur l’organisation des tests et la configuration des plans explique le rôle de ces plans.

Pour éviter une correction au mauvais endroit, procédez ainsi :

• [ ] Identifiez la cible qui contient les tests Swift Testing et XCTest concernés.
• [ ] Ouvrez le plan de test réellement sélectionné pour cette cible, plutôt qu’un plan portant un nom similaire.
• [ ] Relevez le mode d’interopérabilité configuré avant toute modification.
• [ ] Exécutez le test témoin qui déclenche l’appel XCTest depuis Swift Testing.
• [ ] Comparez le résultat enregistré, sa gravité et la suite de l’exécution avec l’attente documentée par l’équipe.
• [ ] Modifiez le plan si nécessaire, puis relancez la même sonde pour confirmer que le résultat correspond à la politique retenue.
• [ ] Notez le réglage dans la procédure de maintenance afin qu’une modification ultérieure du plan ne passe pas inaperçue.

Si votre dépôt possède plusieurs plans, consignez la valeur par plan et par cible. Une observation faite avec le plan de développement ne permet pas de conclure que le plan de CI partage la même configuration. Pour interpréter l’évolution du comportement dans Xcode 27, confrontez vos observations à la présentation WWDC26 et aux notes de version, sans généraliser un exemple de démonstration à tous les projets.

Un paquet Swift et un projet Xcode ne présentent pas nécessairement leurs réglages au même endroit, ni avec les mêmes valeurs effectives. Les paramètres peuvent dépendre de la configuration de l’outil, de la version de la chaîne Swift et de swift-tools-version. Il faut donc vérifier l’environnement réellement utilisé ; le nom du projet ou la version affichée dans l’interface ne prouvent pas à eux seuls quel comportement s’applique.

Le mode par défaut est-il identique dans un paquet Swift et dans un projet Xcode ? Ne le présumez pas. Vérifiez les indications officielles applicables au contexte de compilation, puis comparez une même sonde exécutée depuis Xcode et depuis la ligne de commande. Si vous utilisez Swift 6.4, consignez cette version avec le résultat : elle décrit un élément de la chaîne d’outils, mais ne remplace pas la vérification du paramètre d’interopérabilité effectif.

Les éléments utiles à relever sont le dépôt et la cible testés, la version de Xcode, la chaîne Swift, la valeur de swift-tools-version pour un paquet, le plan de test sélectionné côté Xcode et l’entrée de commande utilisée côté terminal. Ne copiez pas une valeur trouvée dans un projet voisin avant d’avoir vérifié qu’il utilise les mêmes outils et le même chemin d’exécution.

Pour comparer les contextes, gardez le test témoin identique et contrôlez que la configuration de compilation ne varie pas. Une différence de résultat peut signaler un réglage d’interopérabilité distinct, mais aussi une divergence de cible, de plan ou de chaîne d’outils. La documentation Apple sur l’exécution des tests et l’interprétation des résultats fournit le cadre pour examiner le lancement en ligne de commande et les rapports produits.

Une politique n’est utile que si le pipeline rend ses effets vérifiables. Pour décider de conserver un mode, vérifiez trois résultats : les problèmes croisés sont-ils enregistrés, leur gravité correspond-elle à la règle de l’équipe, et les tests XCTest existants continuent-ils à fonctionner comme prévu ? Si une réponse manque, la migration n’est pas encore acceptée.

Faites une exécution de référence avec le test témoin dans le contexte local, puis répétez-la avec l’entrée réellement employée par la CI. Comparez le plan sélectionné, les réglages de la cible, la chaîne Swift et le rapport de test. Ne vous contentez pas de constater que la commande se termine sans erreur : un pipeline peut être vert tout en n’affichant plus le signal que votre équipe cherche à surveiller.

Pour rendre l’examen reproductible, conservez une courte fiche d’essai comprenant le commit, le plan utilisé, le mode, la chaîne d’outils, le chemin d’exécution et le résultat attendu. Ajoutez-y le rapport ou l’extrait qui prouve la gravité observée. Cette preuve permet de distinguer une régression de configuration d’un changement de code lorsque la suite sera exécutée sur un autre nœud ou après une mise à jour des outils.

Si le résultat diffère, ne changez pas immédiatement de mode. Vérifiez d’abord si les deux exécutions utilisent le même plan. Ensuite, confirmez la cible et la chaîne d’outils, puis reproduisez le cas minimal. Cette séquence évite d’attribuer au framework une divergence qui vient en réalité du chemin d’exécution.

Pour l’acceptation, choisissez ensuite une stratégie cohérente : conserver temporairement une configuration de compatibilité, adopter complete pendant la migration, ou appliquer strict là où une règle d’équipe est prête. Gardez des configurations distinctes seulement si elles correspondent à des objectifs explicitement différents et si la CI les teste. Dans tous les cas, évitez de fermer les yeux sur un problème parce qu’il apparaît uniquement dans une exécution distante.

La validation à distance porte sur la cohérence des outils et des paramètres, pas sur une promesse abstraite de performance. Sur un Mac distant, vérifiez quelle version de Xcode est lancée, quel plan de test est sélectionné, quelle chaîne Swift est utilisée et comment le travail est déclenché. Une session graphique et une commande exécutée par un agent d’intégration peuvent ne pas emprunter le même chemin de configuration.

Reprenez le test témoin sur le nœud distant, puis confrontez son résultat à l’exécution locale. Si les résultats divergent, archivez d’abord les éléments qui permettent de reproduire le cas : commit, cible, plan, mode et informations de chaîne d’outils. N’affirmez pas que le nœud distant est la cause avant d’avoir établi que ces éléments sont identiques.

Vous pouvez consulter les guides CALMVPS consacrés aux environnements Mac pour préparer le contexte de développement, puis examiner les informations de location si vous devez disposer d’un Mac accessible pour exécuter vos validations. Ces ressources ne remplacent pas le contrôle du plan de test : la preuve de cohérence reste le même test observé avec les mêmes paramètres sur chaque chemin d’exécution.

Pour votre prochaine validation, commencez par relever le mode du plan existant, puis comparez le test témoin en local et en CI. Si vous ne disposez pas d’un Mac sur lequel exécuter les tests Xcode, un environnement Linux ne peut pas remplacer cette étape de validation propre à la chaîne Apple. L’achat d’un Mac est pertinent si vous avez besoin d’une machine dédiée en permanence ou de connexions matérielles locales ; il implique toutefois l’achat et la maintenance d’un appareil, et ne résout pas à lui seul les divergences de configuration entre plans. Pour une campagne de migration ou un environnement de test temporaire, la location d’un Mac auprès de CALMVPS peut vous donner un contexte d’exécution réel sans achat de matériel. La décision technique reste la même : choisissez votre mode à partir des résultats observés, pas pour rendre le tableau de CI artificiellement vert.