Swift Testing ou XCTest ? Guide de choix pour débutants 2026

Swift 6.4 est une version publiée de Swift, et la documentation officielle confirme que Swift Testing et XCTest peuvent cohabiter dans une même cible de test (publication Swift 6.4 ; guide Apple sur l’ajout de tests). La décision est donc simple : pour un nouveau projet, choisissez Swift Testing pour les tests unitaires et d’intégration ; gardez XCTest pour les tests d’interface et les anciens travaux. Il n’est pas nécessaire de tout réécrire.

Ce guide s’adresse aux débutants qui découvrent @Test, #expect et XCTestCase, aux étudiants qui suivent encore un ancien cours, ainsi qu’aux personnes limitées à Windows ou à un ordinateur scolaire. L’objectif est de choisir un chemin qui fonctionne réellement pour le devoir à rendre, plutôt que de suivre une nouveauté sans vérifier la compatibilité du projet.

Dernière mise à jour : 18 septembre 2026. Les informations de version et d’interopérabilité ont été vérifiées à partir de la documentation Apple, de la page des exigences système de Xcode et de la publication Swift 6.4.

Le choix rapide selon le profil de l’étudiant

Un test ressemble à une vérification automatique avant de rendre un devoir. Au lieu de relire manuellement chaque résultat, le programme contrôle si une fonction renvoie la valeur attendue. La différence entre les deux cadres apparaît surtout dans le type de travail demandé.

Ce tableau ne signifie pas que Swift Testing est « meilleur » dans tous les cas. Il indique plutôt quel outil correspond à la question posée par le test.

Première étape : reconnaître ce que le test doit vérifier

Pour un débutant, le mot « test » recouvre souvent deux exercices différents. Le premier vérifie une règle. Le second reproduit l’action d’une personne dans une application.

Prenons une fonction qui calcule une note :

func mention(for score: Int) -> String {
    score >= 10 ? "Réussi" : "À revoir"
}

Avec Swift Testing, un contrôle minimal peut ressembler à ceci :

import Testing

@Test
func uneNoteSuffisanteEstValidee() {
    #expect(mention(for: 12) == "Réussi")
}

@Test indique au système qu’il s’agit d’un test à exécuter. #expect joue le rôle de la condition de correction : il vérifie que le résultat obtenu correspond à ce qui était prévu. La documentation Apple sur les attentes explique le rôle de ces vérifications dans l’exécution d’un test (documentation Apple sur #expect).

Dans un devoir, cela revient à écrire une règle de correction lisible :

• la fonction reçoit une note ;
• elle renvoie un statut ;
• le test vérifie le statut attendu.

Un test d’interface répond à une autre question : l’élève peut-il ouvrir l’écran, appuyer sur un bouton et voir le résultat ? Cette fois, il faut observer l’application en fonctionnement. Les tests d’interface restent donc associés à XCTest, comme l’explique la documentation Apple consacrée aux cas de test et méthodes XCTest (définition des cas XCTest).

Attention : un test de logique qui passe ne prouve pas que l’écran fonctionne. Inversement, un test d’interface réussi ne vérifie pas toutes les règles internes de l’application.

Swift Testing ou XCTest pour un nouveau projet SwiftUI ?

Pour un projet créé récemment, Swift Testing est le choix le plus cohérent pour les nouvelles fonctions, les règles métier et les contrôles d’intégration. Sa syntaxe décrit directement le comportement attendu. Les tests paramétrés permettent aussi de vérifier une même règle avec plusieurs jeux de données, au lieu de recopier une fonction pour chaque cas.

Le principe est proche d’une série d’exercices corrigés avec la même consigne :

import Testing

@Test(
    arguments: [
        (12, "Réussi"),
        (8, "À revoir")
    ]
)
func uneMentionEstCalculee(score: Int, resultat: String) {
    #expect(mention(for: score) == resultat)
}

Ce code vérifie plusieurs entrées à partir d’une seule description. Pour un étudiant, l’intérêt est concret : une nouvelle valeur peut être ajoutée à la liste sans dupliquer toute la structure du test. Les possibilités de tests paramétrés et l’organisation générale de Testing sont décrites dans la documentation officielle Apple sur le framework (documentation Testing).

La gestion de tâches concurrentes constitue également une raison de privilégier Swift Testing dans du nouveau code Swift. Il ne s’agit pas de déclarer automatiquement que les tests seront plus rapides. Le choix porte plutôt sur la manière dont le cadre s’intègre aux modèles modernes du langage.

Pour l’interface SwiftUI, la séparation reste indispensable :

• Swift Testing vérifie une fonction de formatage, une règle de validation ou une logique de modèle ;
• XCTest vérifie l’affichage, la navigation et les interactions ;
• les deux résultats doivent être consultés dans Xcode avant la remise du projet.

Le cours demande parfois une seule cible de test, parfois des cibles distinctes. Il faut donc suivre la structure du projet fourni au lieu de déplacer les fichiers au hasard.

Ancien cours, devoir existant : ne changez pas avant de vérifier

Un étudiant qui découvre Swift Testing pendant un cours fondé sur XCTest n’a pas intérêt à remplacer immédiatement chaque XCTestCase. La première priorité est plus simple : le projet doit s’ouvrir, compiler, exécuter ses tests et produire le format de résultat attendu par l’enseignant.

Un ancien test peut rester tel quel :

import XCTest
@testable import MonProjet

final class MentionTests: XCTestCase {
    func testUneNoteSuffisanteEstValidee() {
        XCTAssertEqual(mention(for: 12), "Réussi")
    }
}

Ce test n’est pas « mauvais » parce qu’il utilise XCTest. Il correspond peut-être exactement au support de cours, aux fichiers distribués et au plan de test déjà configuré. Une migration précipitée peut créer plusieurs problèmes :

• le nom de la méthode n’est plus reconnu par l’ancien plan de test ;
• une aide partagée attend une instance de XCTestCase ;
• l’enseignant ne retrouve pas la structure demandée ;
• un test ignoré est confondu avec un test réussi ;
• le projet utilisé pour la correction ne possède pas la même configuration.

Apple documente la migration progressive et la coexistence des cadres dans une cible de test (guide de migration depuis XCTest). La bonne méthode consiste à ajouter un nouveau test Swift Testing, exécuter l’ancienne série, puis comparer les échecs. La migration devient alors une série de petits changements vérifiables, non une réécriture globale.

Deuxième étape : décider selon le devoir, pas selon la nouveauté

La décision peut être prise avec les conditions suivantes :

• Si le projet est nouveau et porte sur de la logique Swift, choisissez Swift Testing.
• Si le test doit cliquer dans une interface, vérifier une navigation ou trouver un élément à l’écran, utilisez XCTest.
• Si le cours fournit déjà des tests XCTest, conservez-les jusqu’à ce que le projet fonctionne dans l’environnement demandé.
• Si de nouveaux comportements doivent être ajoutés à un ancien projet, écrivez-les en Swift Testing seulement après avoir vérifié que les deux cadres sont acceptés.
• Si le devoir doit être remis prochainement, ne lancez pas de migration structurelle ; corrigez d’abord les tests déjà attendus.
• Si les résultats semblent différents après migration, revenez à la version précédente et comparez la même série de tests avant de continuer.

Cette dernière condition est importante. Une migration réussie ne se mesure pas au nombre de fichiers renommés. Elle se mesure au fait que les mêmes erreurs sont toujours détectées et correctement affichées.

Projet d’équipe ou ancien dépôt : inspecter avant de modifier

Dans un projet repris par un étudiant, le choix dépend moins d’une préférence personnelle que de l’organisation du dépôt. Avant d’ajouter Swift Testing, il faut examiner :

• les fichiers de test déjà présents ;
• les fonctions auxiliaires partagées ;
• les cibles de test dans Xcode ;
• les plans de test ;
• les versions de Swift et de Xcode indiquées par le projet ;
• la manière dont l’équipe interprète un test ignoré, échoué ou non exécuté.

Les mécanismes d’interopérabilité peuvent varier selon la configuration du projet et du plan de test. Les informations publiées autour de Xcode 27 et de Swift 6.4 doivent donc être vérifiées dans l’environnement réel, et non déduites uniquement du nom du framework (exigences système de Xcode ; présentation WWDC26 sur la migration).

La procédure prudente est la suivante :

Premièrement, créer un point de sauvegarde du dépôt. Deuxièmement, exécuter les tests existants sans modification. Troisièmement, noter les échecs réels et les tests non exécutés. Quatrièmement, ajouter un seul test Swift Testing indépendant. Enfin, relancer l’ensemble et vérifier l’affichage des résultats dans Xcode.

Si un test ne s’exécute pas mais que le projet affiche seulement un avertissement, le problème ne doit pas être considéré comme résolu. Le résultat à comparer est celui observé dans la zone de tests de Xcode, pas uniquement celui de la compilation. La documentation Apple explique comment lancer les tests et interpréter leurs résultats (exécution et lecture des résultats).

Sans Mac : ce qui peut être appris et ce qui doit être vérifié sur Xcode

Swift Testing repose sur Swift et peut servir à pratiquer de la logique dans un Swift Package compatible. La page officielle de Swift indique les plateformes prises en charge par le package de test (package Swift Testing). Cela permet de travailler sur une fonction, d’écrire des cas de données et de comprendre la différence entre une attente correcte et un échec.

La limite apparaît lorsque l’exercice devient un projet iOS ou SwiftUI. La création d’une interface, le simulateur, l’intégration Xcode et les tests d’interface ne sont pas équivalents à l’exécution d’un simple fichier Swift. Une machine Windows peut donc servir à pratiquer une partie de la logique, sans garantir que le devoir iOS complet sera validé.

Un parcours à distance peut rester organisé :

1. écrire une petite fonction Swift et son test ;
2. placer le code dans un dépôt synchronisé ;
3. ouvrir le projet sur un environnement Mac compatible ;
4. exécuter les tests Swift Testing ;
5. lancer le test XCTest d’interface ;
6. conserver les résultats ou les captures demandées par le cours.

Pour comprendre les possibilités d’un environnement Mac distant, les étudiants peuvent consulter la page Mac distant pour travailler avec Xcode. Si l’exercice est ponctuel, il est préférable de tester d’abord le projet complet avant de prévoir une utilisation plus longue. La page tarifs de location d’un Mac permet ensuite de comparer la durée nécessaire avec l’achat d’un appareil.

Cette approche convient également aux projets créatifs. Une application audio peut tester la conversion de paramètres avec Swift Testing, puis vérifier avec XCTest que les commandes de lecture sont accessibles à l’écran. Un projet vidéo peut contrôler la logique d’une liste de plans, puis automatiser l’ouverture d’un élément et le retour à la vue précédente. Le principe reste identique : logique interne d’un côté, parcours utilisateur de l’autre.

FAQ pour débuter sans mélanger les cadres

Quel choix pour un nouveau projet Swift ?

Pour une nouvelle logique, Swift Testing est le choix recommandé. Le code décrit directement le test avec @Test et #expect. Si le projet contient aussi une interface iOS, cela ne supprime pas XCTest : les deux cadres remplissent des fonctions différentes et peuvent être ajoutés au même parcours de validation.

Une ancienne série XCTest doit-elle être réécrite ?

Non. Une ancienne série doit d’abord rester exécutable dans le cadre du cours. La réécriture n’a de sens que si le projet, l’enseignant et le plan de test l’acceptent. Dans la plupart des situations d’apprentissage, l’ajout progressif d’un nouveau test est moins risqué qu’une conversion complète juste avant la remise.

Swift Testing remplace-t-il les tests d’interface ?

Non. Un test Swift Testing peut contrôler une règle interne, mais il ne reproduit pas nécessairement les actions d’un utilisateur dans une application. Pour cliquer, faire défiler, rechercher un élément ou vérifier une navigation, XCTest reste le cadre à conserver. Une application SwiftUI peut donc utiliser les deux.

Les deux cadres fonctionnent-ils dans une même cible ?

Oui, sous réserve de la version et de la configuration du projet. La coexistence permet de laisser les tests XCTest existants en place et de réserver Swift Testing aux nouveaux contrôles. Après l’ajout, il faut exécuter toute la cible et vérifier que les tests ne sont ni ignorés ni simplement absents des résultats.

Que peut faire un étudiant sans Mac ?

Il peut commencer par une fonction Swift, un Swift Package et des données de test compatibles avec son environnement. Il ne peut toutefois pas assimiler cette étape à la validation d’une application iOS complète. Dès que le devoir exige Xcode, SwiftUI, un simulateur ou une automatisation d’interface, un Mac compatible devient nécessaire.

Contrôle avant la remise du devoir

Avant d’envoyer un projet, l’étudiant devrait vérifier les points suivants :

• les tests de logique sont réellement détectés et exécutés ;
• un échec volontaire apparaît comme un échec, puis repasse correctement après correction ;
• les tests d’interface XCTest ouvrent le bon écran ;
• les tests Swift Testing et XCTest sont placés dans la cible attendue ;
• le projet correspond aux versions demandées par le cours ;
• les fichiers auxiliaires et plans de test sont inclus ;
• le projet peut être ouvert et exécuté dans l’environnement de correction ;
• aucune migration n’a supprimé un contrôle utile de l’ancien projet.

Le test volontaire est particulièrement instructif pour un débutant. Il permet de distinguer « le projet compile » de « le test a effectivement contrôlé le comportement ». Une compilation réussie ne remplace pas l’exécution des assertions.

Le choix final pour 2026

Pour un nouveau projet Swift, la recommandation est nette : Swift Testing pour les tests unitaires et d’intégration, XCTest pour les tests d’interface. Pour un ancien cours ou un dépôt existant, la coexistence est plus sûre qu’une conversion totale. Pour un étudiant sans Mac, la logique Swift peut être étudiée séparément, mais la validation iOS doit être réalisée dans un environnement Xcode compatible.

Un Mac personnel offre une disponibilité immédiate, mais son achat peut être disproportionné pour un seul devoir ou une période d’apprentissage incertaine. À l’inverse, un ordinateur scolaire peut imposer des droits limités, une session courte ou l’absence des outils requis. Le Mac distant ajoute une dépendance au réseau et à la qualité de la connexion, mais il évite l’achat immédiat et permet de vérifier le projet réel dans macOS.

Dans ce contexte, SFTPMAC peut servir de solution temporaire pour ouvrir Xcode, exécuter les deux familles de tests et terminer une validation lorsque le poste habituel ne suffit pas. Il faut néanmoins vérifier la durée du cours, la stabilité de la connexion et les besoins de périphériques physiques avant de choisir la location plutôt qu’un appareil local. Pour un essai ciblé ou une remise de projet, la comparaison des options Mac disponibles pour les étudiants constitue un point de départ plus prudent qu’un achat décidé uniquement pour suivre un tutoriel.