150 votes

Bibliothèques non trouvées lors de l'utilisation de CocoaPods avec des tests logiques iOS

J'essaie d'écrire des tests logiques iOS pour les classes de mon projet qui utilisent des fonctionnalités de certaines bibliothèques de mon podspec. J'utilise le paquet de tests unitaires standard fourni dans Xcode (mais pas les tests d'application, seulement les tests unitaires).

Par exemple, j'utilise Magical Record, et cette bibliothèque est liée à mon podspec. Elle est présente dans le projet Pods de mon espace de travail et fonctionne comme prévu lorsque l'application est exécutée dans le simulateur ou sur l'appareil. Cependant, lorsque j'essaie de lier au test l'objet qui utilise Magical Record, j'obtiens une erreur de liaison indiquant qu'il ne peut pas trouver les sélecteurs de Magical Record. J'ai essayé de mettre à jour mon HEADER_SEARCH_PATH dans mon bundle de test logique, et même de le coder en dur vers le répertoire des headers 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 m'y prends mal ? Devrais-je faire autre chose pour que le compilateur voie les bibliothèques CocoaPods ?

225voto

Keith Smiley Points 9760

CocoaPods 1.0 a modifié la syntaxe de cette opération. 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

Réponse de Pre CocoaPods 1.0

Ce que vous voulez utiliser est link_with de votre Podfile . Quelque chose comme :

link_with 'MainTarget', 'MainTargetTests'

Ensuite, exécutez pod install encore.

7 votes

Cela a immédiatement réglé le problème pour moi.

9 votes

J'obtiens des erreurs étranges avec ceci - lors des tests, isSubclassOfClass: appels retour NO où ils doivent retourner YES . La seule raison pour laquelle je peux expliquer cela est que les dépendances sont réellement liées à la fois à la cible principale et à la cible de test, et lorsque le chargeur de bundle de la cible de test charge le bundle principal, il ne peut pas décider quelle classe prendre.

4 votes

J'ai le même problème avec isKindOfClass: en retournant sur NO alors qu'il devrait retourner YES . Si j'enregistre le pointeur vers le Class de l'objet que je teste et le Class de la classe à laquelle je veux comparer, ce sont deux valeurs différentes. Il est clair que le code du paquet d'applications utilise un symbole différent pour la classe que le code de mes tests unitaires. Quelqu'un a-t-il trouvé un moyen de résoudre ce problème ?

174voto

Mark Struzinski Points 11288

Je l'ai découvert en regardant comment la cible principale 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 de l'en-tête.

Si vous regardez votre projet dans le navigateur de projet et cliquez sur l'onglet Info, vous verrez vos configurations de construction répertoriées dans la section supérieure. Si vous ouvrez le triangle de divulgation de vos différentes configurations, vous verrez que Pods est listé sous votre cible principale. J'ai dû cliquer sur le menu déroulant et ajouter des pods à la cible de test logique également.

Configurations Snapshot

J'ai également dû copier les paramètres de $(inherited) y ${PODS_HEADERS_SEARCH_PATHS} de ma cible principale et les copier sur la cible de test logique sous Build Settings/HEADER_SEARCH_PATHS.

Enfin, j'ai dû ajouter libPods.a dans la phase de construction Link Binary with Libraries pour ma cible de tests logiques.

J'espère que cela pourra aider quelqu'un d'autre.

0 votes

Brillant ! J'utilise MagicalRecord et aussi OCMockito et OCHamcrest pour les tests unitaires. Avec cette correction, je peux maintenant les installer tous via CocoaPods ! Merci !

4 votes

Cela a fonctionné pour moi, merci. NOTE.. Je n'ai pas eu besoin d'ajouter la libPods.a dans le projet de test et le projet principal. Cela provoque une erreur de symbole dupliqué

0 votes

Pour moi, j'ai également dû copier les paramètres de construction "définis par l'utilisateur". Les chemins de recherche de l'en-tête font référence à $PODS_ROOT qui n'était pas défini sur la cible de test. Vous pouvez l'ajouter en allant dans Editor->Add Build Setting->Add User-Defined Setting puis en copiant la valeur $PODS_ROOT de la cible principale.

53voto

Flow Points 698

Il existe une solution que j'ai trouvée ici Tests unitaires avec CocoaPods :

Ouvrez le fichier du projet dans Xcode, puis choisissez le projet (pas la cible), dans le panneau de droite, il y a une section appelée Configurations. Choisissez Pods dans la colonne "Based on Configuration file" pour votre cible de test.

enter image description here

0 votes

Et s'il y a des dépendances spécifiques au test, comme par exemple Specta que vous voulez lier avec le projet de test mais pas avec le projet principal ? :S

0 votes

Cela a fonctionné et ne nécessite aucune modification de la configuration ou de l'installation du pod... Excellente solution.

1 votes

Bien que cette solution puisse créer une erreur : Class Foo is implemented in both MyApp and MyAppTestCase. One of the two will be used. Which one is undefined. Cela semble être causé par un bogue dans Cocoapods ; voir la réponse de @JRV ci-dessous.

5voto

Qw4z1 Points 1289

Ma solution à ce problème a été de modifier mon Podfile pour inclure la bibliothèque dans les deux cibles comme ceci

target "MyApp" do  
    pod 'GRMustache', '~> 7.0.2'
end

target "MyAppTests" do
    pod 'GRMustache', '~> 7.0.2'
end

Et comme j'utilise swift, j'ai également dû configurer la cible de test pour qu'elle comprenne le fichier MyApp-Bridging-Header.h fichier. (Dans le groupe Compilateur Swift, sous l'onglet Paramètres de construction)

3 votes

Attention, cela augmentera considérablement le temps de construction, car vous ajouterez sans cesse de nouvelles nacelles !

0 votes

@fatuhoku ne le savait pas. Pouvez-vous nous expliquer pourquoi cela augmente le temps de construction ?

2 votes

Eh bien, chaque mention d'une cosse est une cible dans votre Pods projet. En mentionnant deux fois vos pods (une fois pour les tests et une fois pour l'application), vous aurez deux ensembles de cibles. Cela double effectivement le travail de configuration pod install doit faire. Ce ne sera pas un problème tant que vous n'aurez pas plus de 15 pods, alors ne vous inquiétez pas trop avant.

4voto

Maxwell Points 967

J'ai connu un cas similaire lorsque j'ai perdu des fichiers de bibliothèque lors d'un contrôle de version. Je voyais toujours le fichier de bibliothèque dans mes pods, mais le code réel étant absent, XCode a indiqué qu'il avait disparu. À mon grand désarroi, l'exécution de "pod install" ne ramenait pas immédiatement les fichiers perdus.

J'ai dû retirer et remplacer la cosse manuellement en procédant comme suit :

  1. Suppression de la bibliothèque du Podfile
  2. Exécutez "pod install" pour supprimer complètement la bibliothèque.
  3. Remettre la bibliothèque dans le Podfile
  4. Exécutez à nouveau "pod install".

Cela devrait remettre la bibliothèque en question dans sa forme originale.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X