2009-08-23 2 views
5

Je ne suis pas encore fan des environnements de développement intégrés, mais j'essaie de surmonter mes préjugés et d'apprendre Xcode. (Eclipse/CDT est la prochaine, je ne pouvais pas obtenir cela pour travailler pour moi quand j'ai essayé l'année dernière, mais c'est un problème distinct.)Comment organiser des tests unitaires d'un projet de bibliothèque dans Xcode?

Je suis en train d'écrire du nouveau code dans un nouveau projet qui deviendra (partie de) une petite bibliothèque. Je veux tester l'unité aussi. Comment puis-je expliquer à Xcode que je construis une bibliothèque (partagée), mais je veux aussi l'utiliser dans un programme de test, compilé à partir d'une source séparée qui ne sera pas dans la bibliothèque partagée?

code source:

  • atom.c
  • atom.h
  • test atom.c

Produit des fichiers:

  • libatom.dylib
  • test-atome

J'ai atom.c et atom.h compilé dans la bibliothèque. Je ne suis pas sûr de savoir comment organiser les choses afin que je puisse également créer test-atom pour lier avec la bibliothèque. Je suppose que quand j'ai trié cela, ajouter la bibliothèque pour le code de support de test que test-atom.c serait relativement simple - même si elle n'est pas encore sous le contrôle de Xcode.

FWIW, je travaille principalement en C plutôt que Objective C.

Répondre

4

Vous avez besoin de deux cibles dans votre projet; une cible dans Xcode produit un produit qui est une bibliothèque, un exécutable ou une autre sortie.

Ainsi vous auriez une cible pour produire libatom.dylib, que je soupçonne que vous avez déjà configuré, et une autre cible exécutable de ligne de commande pour produire l'exécutable test-atom pour que vous exécutiez pour tester votre bibliothèque.

Une fois que vous avez ajouté la cible test-atom, vous devriez Obtenir des informations sur test-atom.c et retirer ses membres de la cible libatom.dylib, et l'ajouter en tant que membre de votre nouvel objectif test-atom. L'appartenance cible d'un fichier est ce qui détermine si la construction d'une cible va essayer de compiler/copier/lier ce fichier. (Qu'est-ce que la cible fait avec le fichier dépend de ce que la phase de construction, il est ajouté quand il est fait membre.)

Vous devez également obtenir des informations dans l'entrée libatom.dylib dans votre groupe de produits, et de faire que membre la cible test-atom également. Cela provoquera le lien test-atom exécutable par rapport à libatom.dylib.

Enfin, Get Info sur la cible test-atom (et non le produit) et dans l'onglet Général, ajouter une dépendance sur la cible libatom.dylib. Cela garantira que la cible test-atom sera toujours la première à générer la cible libatom.dylib.

2

Edit: Voir Automated Unit Testing with Xcode 3 and Objective-C (une version plus récente de l'article I initialement lié à, comme souligné dans un commentaire ci-dessous). Voir également What is the best way to unit test Objective-C code? Bien que vous n'utilisiez pas encore Obj-C, les bases de la configuration de nouvelles cibles seront les mêmes pour le code C, et les informations spécifiques à OCUnit sont très représentatives du fonctionnement des tests unitaires dans un IDE.

+4

Veuillez ne pas diriger les gens vers "Tester votre code avec OCUnit" - c'est obsolète, et a été grossièrement démodé depuis quelques mois après sa publication. D'une part, il dit aux gens de télécharger OCUnit, mais OCUnit a été inclus avec Xcode depuis la WWDC 2005 lorsque Xcode 2.1 a été publié. Merci de diriger les utilisateurs vers "Tests unitaires automatisés avec Xcode 3 et Objective-C" http://developer.apple.com/mac/articles/tools/unittestingwithxcode3.html à la place. –

+0

Merci de pointer vers le nouvel article! –

Questions connexes