J'essaie d'écrire des tests de logique iOS sur des classes de mon projet qui utilisent les fonctionnalités de certaines des bibliothèques de mon podspec. J'utilise le kit de tests unitaires standard fourni dans Xcode (bien que ce ne soit pas des tests d'application, mais uniquement des tests unitaires).
Par exemple, j'utilise Magical Record et cette bibliothèque est liée à mon podspec. Il est présent dans le projet Pods dans mon espace de travail et fonctionne comme prévu lorsque l'application s'exécute dans le simulateur ou sur le périphérique. Cependant, lorsque j'essaie de lier au test l'objet qui utilise Magical Record, un message d'erreur indiquant qu'il ne trouve pas les sélecteurs dans Magical Record s'affiche. J'ai essayé de mettre à jour mon HEADER_SEARCH_PATH dans mon ensemble de tests logiques, même en le codant de manière définitive dans le répertoire des en-têtes créé par CocoaPods, mais sans succès.
Je peux exécuter des tests unitaires sur des classes qui n'utilisent pas les bibliothèques CocoaPods sans problème.
Est-ce que je me trompe? Devrais-je faire quelque chose d'autre pour que le compilateur voie les bibliothèques CocoaPods?
Je l'ai compris en regardant comment l'objectif principal de mon application recevait les paramètres de la bibliothèque CocoaPods. CocoaPods inclut un fichier .xcconfig nommé Pods.xcconfig. Ce fichier contient tous les chemins de recherche en-tête.
Si vous examinez votre projet dans le navigateur de projet et que vous cliquez sur l'onglet Informations, vos configurations de construction apparaissent dans la section supérieure. Si vous ouvrez le triangle d'affichage de vos différentes configurations, les pods apparaissent sous votre cible principale. Je devais cliquer sur le menu déroulant et ajouter des pods à la cible du test de logique également.
Je devais également copier les paramètres de $(inherited)
et ${PODS_HEADERS_SEARCH_PATHS}
à partir de ma cible principale et les copier vers la cible de test logique sous Paramètres de construction/HEADER_SEARCH_PATHS.
Enfin, j'ai dû ajouter libPods.a lors de la phase de construction du lien binaire avec bibliothèques pour ma cible de tests logiques.
J'espère que cela pourra aider quelqu'un d'autre.
CocoaPods 1.0 a changé la syntaxe pour cela. Cela ressemble maintenant à ceci:
def shared_pods
pod 'SSKeychain', '~> 0.1.4'
...
end
target 'Sail' do
shared_pods
end
target 'Sail-iOS' do
shared_pods
end
Pre CocoaPods 1.0 réponse
Ce que vous voulez utiliser est link_with
de votre Podfile
. Quelque chose comme:
link_with 'MainTarget', 'MainTargetTests'
Ensuite, exécutez à nouveau pod install
.
J'ai trouvé ici une solution Tests unitaires avec CocoaPods :
Ouvrez le fichier de projet dans Xcode, puis choisissez le projet (pas la cible). Dans le panneau de droite, il existe une section intitulée Configurations. Choisissez Modules dans la colonne "Basé sur le fichier de configuration" pour votre cible de test.
Je suis d'accord avec les autres réponses disant qu'il est nécessaire de relier les bibliothèques aux cibles de test. Cependant aucune des suggestions jusqu'ici m'a aidé. Comme @fabb écrit dans un commentaire: "lors du test, les appels isSubclassOfClass:
renvoient NON où ils doivent renvoyer YES. La seule raison pour laquelle je peux expliquer cela est que les dépendances sont vraiment liées à la fois à la cible principale et à la cible de test, et lorsque la cible de test le chargeur de paquet charge le paquet principal, il ne peut pas décider quelle classe prendre. " Je reçois le même problème avec toutes les suggestions précédentes dans ce fil.
La solution à laquelle je me suis mis au travail consistait à mettre à jour mon fichier podfile afin de définir des pods spécifiques pour ma cible principale et pour ma cible de test:
target 'MyTarget' do
pod 'AFNetworking', '~> 2.5.0'
pod 'Mantle', '~> 1.5'
end
target 'MyTargetTests' do
pod 'OCMockito', '~> 1.3.1'
end
Il était nécessaire de spécifier un pod pour ma cible de test même si je n'ai utilisé aucun pod spécifique au test. Sinon, CocoaPods n’insérerait pas la logique de liaison nécessaire dans mon projet.
Ce lien est ce qui m'a aidé à arriver à cette conclusion.
J'ai ajouté :exclusive => true
pour éviter les erreurs de symbole dupliquées dans la cible de test de l'application.
target 'myProjectTests', :exclusive => true do
pod 'OCMock', :head
pod 'XCTAsyncTestCase', :git => 'https://github.com/iheartradio/xctest-additions.git'
end
link_with 'myProject', 'myProjectTests'
Lorsque j'ai remplacé l'objectif de test d'application par le test d'unité logique, l'erreur de l'éditeur de liens s'est produite . Après avoir supprimé :exclusive => true
, tout fonctionne à nouveau.
target 'myProjectTests', do
pod 'OCMock', :head
pod 'XCTAsyncTestCase', :git => 'https://github.com/iheartradio/xctest-additions.git'
end
link_with 'myProject', 'myProjectTests'
:exclusive => true
indique que tout ce qui est en dehors de do...end
NE DOIT PAS être lié à myProjectTests
, ce qui est raisonnable dans les cibles de test d'application, mais cela entraînera des erreurs de l'éditeur de liens dans les cibles de test logique.
Vous pouvez utiliser link_with selon la solution @Keith Smiley.
Si vous avez des pods communs et des spécificités pour chaque cible, vous pouvez utiliser l’option "def" pour définir un groupe de pods. et utiliser le "def" plus tard dans la cible exclusive.
def import_pods
pod 'SSKeychain'
end
target 'MyProjectTests', :exclusive => true do
import_pods
end
target 'MyProject', :exclusive => true do
import_pods
pod 'Typhoon'
end
dans l'exemple ci-dessus, j'ai ajouté 'SSKeychain' aux deux cibles et 'Typhoon' uniquement à la cible 'MyProject'
Ma solution à ce problème a été de changer mon Podfile pour inclure la bibliothèque dans les deux cibles comme celle-ci.
target "MyApp" do
pod 'GRMustache', '~> 7.0.2'
end
target "MyAppTests" do
pod 'GRMustache', '~> 7.0.2'
end
Et depuis que j'utilise Swift, je devais également configurer la cible de test pour inclure le fichier MyApp-Bridging-Header.h
. (Dans le groupe Compilateur Swift, sous l'onglet Paramètres de construction)
J'ai eu un événement similaire lorsque j'ai perdu des fichiers de bibliothèque lors d'un contrôle de version. J'ai encore vu le fichier de bibliothèque dans mes pods, mais avec le code réel manquant, XCode a dit qu'il était parti. À mon grand désarroi, l'exécution de '' installation du pod '' ne rapportait pas immédiatement les fichiers perdus.
J'ai dû retirer et remplacer le pod manuellement en procédant comme suit:
Cela devrait remettre la bibliothèque en question dans sa forme originale.
A partir de CocoaPods 1.x, il existe un nouveau moyen de déclarer des dépendances partagées entre une cible et la cible de test correspondante. J'avais utilisé la solution acceptée par Mark Struzinski jusqu'à présent, mais cette méthode a généré un grand nombre d'avertissements lors de l'exécution de mes tests:
Class SomeClass is implemented in both /Path/To/Test/Target and /Path/To/App/Target. One of the two will be used. Which one is undefined.
Avec CocoaPods 1.x, nous pouvons déclarer notre cible -Test comme héritant via les chemins de recherche de la cible parent, comme suit:
target 'MyApp' do
pod 'aPod'
pod 'anotherPod'
project 'MyApp.xcodeproj'
end
target 'MyAppTests' do
inherit! :search_paths
project 'MyApp.xcodeproj'
end
Ainsi, la cible -Test aura accès aux dépendances de la cible de l'application, sans plusieurs copies binaires. Cela a sérieusement accéléré les temps de construction des tests pour moi.
Il est également intéressant de noter que si vous avez ajouté deux fois libPods.a
, vous obtiendrez une mauvaise erreur comme celle-ci:
232 duplicate symbols for architecture i386
Pour résoudre ce problème, supprimez simplement l'une des références libPods.a
de votre explorateur de projet.
Essayez ça ça marche pour moi,
Nous devons définir des pods dans les configurations,
Le projet-> Info-> Configurations dans le projet Xcode (votre projet) doit être défini sur le projet principal "Pods" pour le débogage, la publication (et ce que vous avez d'autre). Voir "En-têtes non trouvés - chemins de recherche non inclus"
J'espère que c'est une aide pour quelqu'un.
Je travaille avec l'intégration de GoogleMaps Objective-C POD sur iOS avec mon application Swift. Le problème était donc que la cible de test ne contenait aucune référence au fichier d'en-tête de pont ( Swift_OBJC_BRIDGING_HEADER ) dans les paramètres de construction. Assurez-vous que les objectifs de votre application et de vos applications de test sont bien orientés afin que les appels d'API tiers (API de cartes, etc.) puissent être utilisés dans les tests unitaires Swift.
La syntaxe suivante donne le meilleur résultat pour moi (testé sous cocoapod v.1.2.1):
https://github.com/CocoaPods/CocoaPods/issues/4626#issuecomment-210402349
target 'App' do
pod 'GoogleAnalytics' , '~> 3.0'
pod 'GoogleTagManager' , '~> 3.0'
pod 'SDWebImage', '~>3.7'
platform :ios, '8.0'
use_frameworks!
target 'App Unit Tests' do
inherit! :search_paths
end
end
Sans cela, j'ai des avertissements lors du test sur les symboles en double.
Après ces avertissements ont disparu.
J'ai eu des problèmes avec OpenCV sous XCTest. Cela me donnait des erreurs de lieur de Undefined symbols for architecture arm64
pour des classes comme cv::Mat
. J'installe OpenCV via CocoaPods en utilisant pod 'OpenCV', '~> 2.0'
sous la cible principale. Peu importe la difficulté avec laquelle j'ai essayé de placer la dépendance OpenCV sous la cible de test ou d'utiliser inherit! :search_paths
, rien de tout cela n'a fonctionné. La solution consistait à créer un abstract_target
comme ceci:
# Uncomment the next line to define a global platform for your project
platform :ios, '6.1.6'
abstract_target 'Shows' do
pod 'RMVision', path: '../..'
pod 'RMShared', path: '../../../RMShared'
pod 'OpenCV', '~> 2.0'
target 'RMVisionSample' do
# Uncomment the next line if you're using Swift or would like to use dynamic frameworks
# use_frameworks!
# Pods for RMVisionSample
end
target 'RMVisionSampleTests' do
# inherit! :search_paths
# Pods for testing
end
target 'RMVisionBenchmarks' do
# inherit! :search_paths
# Pods for testing
end
end
Les commandes pod deintegrate
& pod clean
permettent également de nettoyer le projet et de vous assurer de tout recommencer à zéro lors des tests. Vous pouvez installer ces deux en utilisant [Sudo] gem install cocoapods-deintegrate cocoapods-clean
.