Swift 6.4 et XCTest : que faire en cas d’erreur d’interopérabilité ? Guide de dépannage 2026

Un test semble réussir alors qu’une assertion paraît ignorée, ou bien un avertissement apparaît après la mise à jour de l’outil.

Repère utile : Swift 6.4 prend en charge une interopérabilité progressive entre Swift Testing et XCTest, mais le résultat dépend aussi de la chaîne d’outils et de la valeur swift-tools-version du paquet. Commencez par identifier le framework qui appelle l’assertion de l’autre, puis vérifiez ces versions et le mode actif ; il n’est généralement pas nécessaire de réécrire les anciens tests. Les notes de publication de Swift 6.4 et le guide officiel de migration décrivent ce périmètre.

Ce guide s’adresse aux étudiants qui font cohabiter un ancien projet de cours fondé sur XCTest et de nouveaux tests Swift Testing. Il convient aussi aux débutants qui mettent à jour leur chaîne d’outils ou leur paquet, ainsi qu’aux personnes dont le compte rendu de tests dans Xcode ne correspond pas au résultat attendu.

Dernière vérification éditoriale : 10 octobre 2026, d’après les documents officiels Swift et les guides de migration et de tests publiés par Apple. Les comportements des versions ultérieures doivent être vérifiés dans leur documentation officielle.

1. Distinguer le symptôme avant de modifier le projet

Le terme « erreur d’interopérabilité » peut désigner des situations différentes. Un test peut apparaître comme réussi alors qu’une assertion appelée depuis une fonction auxiliaire ne produit pas l’échec attendu ; le compilateur peut aussi afficher un avertissement, ou bien le test peut échouer franchement. Ces résultats ne conduisent pas au même diagnostic.

Avant de toucher aux réglages, ouvrez le rapport complet de la dernière exécution et notez ce qui s’est réellement passé. Le résumé global ne suffit pas toujours : un test non exécuté, un test ignoré et un test réussi ne prouvent pas la même chose.

• Résultat positif douteux : le test est indiqué comme réussi, mais les données qui devraient déclencher une assertion ne sont pas signalées.
• Avertissement ou message de modernisation : l’exécution continue, mais le compilateur ou le rapport mentionne un appel entre frameworks.
• Échec explicite : le test s’est lancé et une assertion, la compilation ou une autre étape a échoué.
• Absence de résultat : le test n’apparaît pas dans le compte rendu ; il faut d’abord vérifier la cible et le plan d’exécution, plutôt que de modifier les assertions.

Swift 6.4 rend certains usages croisés possibles, mais cela ne signifie pas que toutes les API, toutes les fonctions auxiliaires ni tous les comportements des deux frameworks deviennent interchangeables. Les notes de version de Swift 6.4 présentent cette évolution comme une prise en charge de l’interopérabilité, pas comme une fusion des outils de test.

2. Suivre l’appel qui relie les deux frameworks

Dans un projet de cours, l’assertion à l’origine du problème est parfois cachée dans une fonction écrite plusieurs semaines auparavant. Un étudiant ajoute ensuite un test Swift Testing qui appelle cette fonction, sans voir que celle-ci contient encore une assertion XCTest. Le nom du test ne révèle donc pas forcément quel framework a produit le résultat.

Pour remonter à l’appel concerné, partez du test qui présente le symptôme et suivez les fonctions auxiliaires qu’il utilise. Recherchez notamment XCTAssert… et #expect, puis notez lequel est appelé directement depuis le test et lequel se trouve derrière une fonction partagée. Cette vérification localisée est plus sûre qu’un remplacement global des assertions.

Peut-on utiliser XCTest et Swift Testing dans un même fichier de test ?

Le point essentiel n’est pas seulement la présence de deux syntaxes dans un fichier : il faut savoir quel framework gère chaque test et quelles assertions sont appelées depuis celui-ci. La documentation de migration décrit des usages croisés pris en charge, mais elle ne garantit pas que chaque combinaison d’API ou chaque organisation de fichiers aura le comportement souhaité. Le guide de migration XCTest vers Swift Testing permet de vérifier les scénarios couverts avant de conclure qu’un fichier mixte est la cause du problème.

Pour obtenir un diagnostic simple, créez, si le projet le permet, un petit cas de test isolé dans la structure déjà utilisée par le cours. Conservez les mêmes imports, le même outil de lancement et la même version du paquet que dans le cas en échec. Si le test isolé fonctionne mais que le test du projet ne fonctionne pas, examinez les fonctions auxiliaires et les paramètres de la cible avant de modifier le mode d’interopérabilité.

Une assertion XCTAssert échoue-t-elle sans apparaître dans le résultat ?

Si un test Swift Testing appelle une fonction auxiliaire qui contient une assertion XCTest, vérifiez d’abord le compte rendu détaillé et le mode d’interopérabilité. Notez le nom exact du test, la fonction appelée, le message affiché et le statut final. Le guide de migration précise les appels pris en charge et la manière dont les problèmes entre frameworks sont rapportés ; la lecture de ce passage est préférable à la supposition selon laquelle toute assertion imbriquée doit nécessairement échouer comme une assertion native au framework du test.

Pour isoler l’appel, conservez un test connu comme valide, puis ajoutez un seul cas contrôlé qui doit échouer. Si l’assertion directe fonctionne mais que celle située dans l’auxiliaire ne produit pas le résultat attendu, l’écart pointe vers le chemin d’appel ou la configuration d’interopérabilité. Si les deux échouent de façon identique, cherchez plutôt une erreur dans les données, la condition testée ou la cible exécutée.

Pourquoi #expect peut-il poser problème dans un test XCTest ?

Un test XCTest qui utilise #expect suit le trajet inverse : c’est le test géré par XCTest qui appelle une assertion de Swift Testing. Ne transposez pas automatiquement à ce cas la conclusion tirée d’un appel XCTAssert dans un test Swift Testing. Vérifiez les deux directions dans le guide officiel, puis comparez le message du rapport avec le scénario décrit pour le mode actif. La proposition d’interopérabilité ST-0021 donne le contexte technique et les limites prévues pour ces échanges.

Si le message concerne une assertion entre frameworks, continuez vers la vérification des versions et du mode. Si le résultat indique plutôt que le test n’a pas été découvert, ignoré ou lancé, le problème se situe probablement ailleurs : la présence de #expect ne suffit pas à prouver une panne d’interopérabilité.

3. Vérifier la chaîne d’outils et la version du paquet

La chaîne d’outils désigne ici le compilateur Swift et les outils qui construisent puis exécutent le projet. Dans une analogie scolaire, c’est l’ensemble « matériel et règles de correction » disponible dans l’environnement de travail. La ligne swift-tools-version, elle, joue le rôle de version du manuel que le paquet déclare pouvoir utiliser : elle est inscrite dans le fichier Package.swift et influence les règles de traitement du paquet.

Ces deux indications ne doivent pas être confondues. Un projet peut avoir été écrit avec une valeur de swift-tools-version donnée, puis être ouvert avec une autre chaîne d’outils. La valeur déclarée ne prouve pas à elle seule quel compilateur a réellement construit les tests. La documentation de Swift Package Manager sur swift-tools-version explique son rôle dans la description du paquet.

Procédez sans modifier immédiatement les fichiers :

1. Reproduisez le problème une fois et notez le test précis, son statut final et le texte complet du diagnostic.
2. Identifiez la cible exécutée : test unitaire, cible de paquet ou autre cible de test. Vérifiez que le rapport provient bien de celle que vous pensez lancer.
3. Relevez la chaîne d’outils utilisée par le projet, puis notez séparément la valeur de swift-tools-version dans Package.swift, si le projet utilise Swift Package Manager.
4. Repérez les appels croisés : recherchez l’assertion dans le test et dans les fonctions auxiliaires, sans remplacer toutes les occurrences.
5. Consultez la documentation correspondant à l’interopérabilité et relevez le mode indiqué dans la configuration réellement utilisée.
6. Comparez avec un exemple minimal : une assertion qui doit réussir et une autre conçue pour échouer, exécutées dans le même environnement.
7. Modifiez un seul élément à la fois, relancez exactement la même cible, puis consignez la différence entre les deux rapports.

Si le projet échoue avant même de découvrir ou de lancer les tests, arrêtez ici le diagnostic d’interopérabilité. Un problème de construction doit être résolu avant de tirer une conclusion sur la façon dont les assertions entre frameworks sont rapportées.

Après une mise à jour, un avertissement peut aussi refléter un changement de règles par défaut plutôt qu’un défaut du code. Le guide de migration explique le lien entre le mode, la chaîne d’outils et la valeur de swift-tools-version ; il faut donc examiner ces éléments ensemble, au lieu de recopier un réglage trouvé dans un ancien tutoriel.

4. Choisir le mode selon le diagnostic, pas selon la couleur du résultat

Les modes none, limited, complete et strict décrivent des degrés ou des règles d’interopérabilité, et ne sont pas des réglages équivalents permettant simplement de faire disparaître une erreur. Le mode actif détermine quelles interactions entre Swift Testing et XCTest sont admises ou comment les situations concernées sont diagnostiquées. Consultez le guide officiel de migration et la proposition ST-0021 avant de décider qu’un mode plus permissif convient au projet.

Voici une règle de décision conditionnelle pour éviter les changements au hasard :

• Si le projet n’utilise volontairement aucun appel croisé, conservez ou choisissez le comportement sans interopérabilité, conformément à la documentation de la chaîne d’outils. Dans ce cas, la priorité est de retirer ou de remplacer les appels croisés réellement présents, pas de cacher leur diagnostic.
• Si le projet dépend d’un scénario croisé précis décrit comme pris en charge, vérifiez que le mode documenté pour ce scénario est celui qui est effectivement appliqué. Testez ensuite les appels dans les deux directions, sans supposer qu’une réussite dans un sens valide l’autre.
• Si le cours ou le projet exige un contrôle plus strict, gardez ce niveau de vérification et corrigez les appels non conformes. N’assouplissez pas le mode uniquement pour obtenir un indicateur vert.
• Si le comportement contredit la documentation, relevez la version des outils, swift-tools-version, le mode, le test minimal et le rapport complet avant toute mise à jour supplémentaire. Sans ces éléments, il est difficile de distinguer une configuration locale d’un problème reproductible.

Pour la variable d’environnement ou l’option qui sélectionne un mode, utilisez le nom exact donné dans la documentation correspondant à l’environnement utilisé. Il est risqué de recopier une commande provenant d’une discussion ancienne : un nom ou une valeur incorrecte peut être ignoré, tandis que l’utilisateur croit avoir changé le mode. La consigne la plus sûre est de vérifier l’option documentée pour la chaîne d’outils effectivement employée, puis de confirmer dans le rapport que le changement a bien eu un effet.

Ne passez pas directement de none à complete ou strict sans comprendre la différence attendue. Les noms seuls ne permettent pas de conclure que le mode le plus large est préférable ; la combinaison prise en charge dépend des interactions dont le projet a réellement besoin. Le guide de migration officiel doit servir de référence pour le comportement documenté de chaque option.

5. Écarter les pannes de cible, de compilation ou de découverte

Un échec dans un projet qui mélange Swift Testing et XCTest n’est pas nécessairement causé par l’interopérabilité. Si la cible de tests n’a pas été exécutée, si le test est ignoré ou si la construction échoue, une assertion croisée ne peut pas expliquer à elle seule l’absence du résultat attendu.

Dans le compte rendu de Xcode, cherchez d’abord si le test apparaît dans la liste et quel statut lui est attribué. Distinguez l’échec pendant la construction, l’échec d’une assertion après exécution et l’absence d’exécution. La documentation officielle sur l’exécution des tests et l’interprétation de leurs résultats décrit les informations à lire dans le rapport. La page consacrée aux tests dans Xcode complète ce repérage.

Une fois la cible confirmée, vérifiez le fichier ou le groupe de tests concerné, les conditions qui peuvent ignorer un test et le plan d’exécution choisi. Ce contrôle est particulièrement utile lorsqu’un projet comprend à la fois des tests unitaires et des tests d’interface : ils ne constituent pas la même cible et ne se lancent pas nécessairement par le même chemin. Il ne s’agit pas de comparer les deux types de tests, mais de vérifier que le compte rendu observé correspond bien au test modifié.

Arrêtez les changements liés au mode si le test n’est pas exécuté du tout. Revenez à la configuration du projet ou à l’étape de compilation indiquée dans le rapport ; reprendre le diagnostic d’interopérabilité n’a de sens qu’une fois qu’un test identifiable est effectivement lancé.

6. Comparer les modes puis confirmer la correction sur deux cas

Le tableau ci-dessous sert à choisir quoi vérifier, et non à remplacer la documentation de version. Les descriptions indiquent le rôle général des options à contrôler ; pour connaître leur effet précis dans un environnement donné, reportez-vous au guide de migration et à la proposition officielle.

Pour valider une correction dans un projet de cours, gardez deux petits tests de référence : le premier doit réussir, le second doit déclencher l’échec attendu. Exécutez-les dans la même cible, avec le même outil et le même mode avant et après le changement. Une correction n’est convaincante que si le cas positif reste positif, que le cas négatif est signalé comme prévu et que le rapport identifie clairement le test concerné.

Consignez au minimum la version de la chaîne d’outils, swift-tools-version, le mode appliqué, l’emplacement de l’appel croisé et le résultat des deux tests. Ce relevé permet de reproduire le comportement sur un autre poste ou de demander de l’aide à un enseignant sans envoyer seulement une capture d’écran du résumé. Il évite aussi de confondre une modification de code avec un changement d’environnement.

Si la difficulté vient du fait qu’aucun Mac ne permet de construire et d’exécuter le projet Xcode, comparez d’abord les solutions disponibles : poste de l’établissement, Mac personnel ou environnement Mac distant. Un poste partagé peut imposer des règles d’installation et des horaires ; un achat n’est pas toujours justifié pour un exercice ponctuel ; un environnement distant dépend, lui, d’une connexion réseau et ne remplace pas un accès physique aux ports de la machine. Pour évaluer une utilisation temporaire, les formules de RUVCLOUD permettent de comparer le coût avant de choisir ; les options de location de Mac RUVCLOUD peuvent être envisagées si le besoin porte surtout sur un environnement macOS accessible à distance.

La location n’est toutefois pas la réponse à un défaut de test : le diagnostic doit d’abord être reproductible et les versions clairement relevées. En revanche, si le blocage vient de l’absence d’un environnement capable d’ouvrir le projet Xcode, un Mac distant peut éviter l’achat d’une machine pour un travail temporaire. Si le projet exige une charge soutenue sur le long terme, un accès permanent à des périphériques ou une utilisation sans dépendre du réseau, un Mac personnel ou celui de l’établissement sera plus adapté.