Cet article sera petit, je vais vous dire quels problèmes sont survenus lors de la création d'une cible à tester dans un projet ObjectiveC + Swift mixte et plutôt ancien, et comment j'ai réussi à les résoudre.
La première chose qui prête à confusion: une erreur dans une cible de test peut affecter le lancement d'un autotest à partir d'une autre cible de test. Vous pouvez ajouter un nombre illimité de cibles à tester dans le projet, elles sont généralement basées sur la cible principale du projet et sont automatiquement ajoutées à son schéma de lancement. Ainsi, lors de l'exécution de tout autotest sur ce schéma, le reste sera compilé et une erreur sur l'une des cibles de test interférera avec le lancement des autres. Pour isoler cet effet, vous pouvez créer différents schémas pour différentes cibles de test.
Je vais joindre une capture d'écran très triviale, uniquement pour plus de clarté:
Le problème suivant concerne les dépendances entre Objecive-C et Swift.
Dans votre projet est créé:
MyProject-Bridging-Header.h : ce fichier contient les noms des fichiers d'en-tête ObjectiveC utilisés dans swift.
MyProject-swift.h : il crée implicitement le code des classes swift utilisées dans les classes ObjectiveC.
MyProject-Prefix.pch : le fichier de précompilation peut également contenir des dépendances de différentes manières, y compris des constructions comme:
#ifdef __OBJC__ #import "MyProject-Swift.h" #endif
Vos autotests peuvent également créer de telles dépendances. Lors de l'ajout du premier fichier swift, Xcode propose de créer un fichier d'en-tête de pont pour cette cible de test. Tout fonctionne comme un charme. En théorie, le contenu de l'autotest de l'en-tête de pont devrait compléter le pont principal, mais en fait, un remplacement se produit. Par conséquent, afin d'avoir accès à toutes les classes du projet dans l'autotest, dans cette option, je spécifie l'en-tête de pont de la cible principale (image ci-dessus).
Accédez à Xcode
Target -> BuildSetting et vérifiez les paramètres suivants:
En-tête de pontage Objective-CNom d'en-tête d'interface généré par Objective-CSpécifiez les principaux fichiers cibles.
Cependant, si vous tirez l'en-tête de pont principal, toutes les dépendances commencent à s'étirer. Par conséquent, vous devez également remplir les paramètres suivants avec les données du projet principal:
Chemins de recherche du frameworkChemins de recherche d'en-têteChemin de recherche de la bibliothèqueAutres drapeaux de l'éditeur de liensLes chemins de recherche de parcours ne doivent
PAS être modifiés.
Puis un autre problème étrange a été découvert:
Pour une raison quelconque, dans les projets plus anciens, la cible de test se voit attribuer le même
nom de module de produit que le principal. Cela n'a pas arrêté le seul ObjectiveC, mais lors de l'ajout rapide au projet, deux problèmes se posent.
Le premier problème est que dans ce cas
@testable import MyProject
le fichier d'autotest est ignoré et vous ne pouvez pas accéder aux classes Swift.
Le deuxième problème est qu'une telle cible à la compilation écrase le MyProject-swift de la cible principale et empêche la compilation d'autres cibles. Ce paramètre doit être renommé.
Sur ce point, mon autotest a commencé et a pu utiliser les fichiers du projet, que je vous souhaite également!
Je ne travaille pas souvent à la mise en place d'un projet, donc tous les commentaires et conseils pratiques sur ce sujet sont les bienvenus.
Merci à tous ceux qui l'ont lu.