Configuration Visual C++ TDD

Question

Je n'ai pas beaucoup travaillé avec Visual Studio auparavant. J'ai commencé un projet personnel pendant mon temps libre et je voudrais utiliser le développement piloté par les tests car cela a été un énorme avantage pour moi dans mon développement Java. J'ai commencé ce projet il y a un certain temps et j'ai utilisé CppUnit. Je sais qu'il y a probablement d'autres cadres qui sont meilleurs, mais c'est ce qui est déjà en place.

Ma solution Visual Stuido 2005 comporte 2 projets. Cela a bien fonctionné lorsque les tests unitaires se sont déroulés juste à côté du code de l'application. Au fur et à mesure que le projet prenait de l'ampleur, cela devenait assez lourd et inélégant. J'ai créé un nouveau projet sous ma solution pour héberger les tests unitaires (il y a donc 3 projets). Tout s'est bien passé jusqu'à ce que j'essaie de construire la solution. Tout a été compilé, mais le projet de test unitaire n'a pas pu être lié. La sortie me donne 51 "symbole externe non résolu" erreurs (LNK2019) pour ce qui semble être chaque fonction que mes tests appellent. Autant que je puisse en déduire, le problème est la structure de répertoires que Visual Studio crée. Chaque projet obtient son propre répertoire, puis en dessous se trouvent les fichiers objets et les exécutables créés. Je pense que le problème est que, bien que les fichiers d'en-tête soient correctement inclus dans chaque test unitaire, l'éditeur de liens ne peut pas trouver les fichiers cpp car ils sont dans un répertoire différent. Quand il ne parvient pas à trouver l'implémentation d'une fonction appelée, il me donne l'erreur 2019.

Ai-je raison dans mon évaluation du problème? Comment puis-je le réparer? Ai-je besoin de réorganiser complètement mes projets ou est-ce une simple configuration de l'éditeur de liens?

Merci

Answer 1

Oui, votre évaluation semble assez bonne. Essayez ceci: Dans l'explorateur de solution, faites un clic droit sur le nom du projet qui contient vos tests et choisissez "Dépendances du projet". Mettez un contrôle sur chaque projet dont il dépend. Cela devrait mettre en place les paramètres de l'éditeur de liens afin qu'il puisse automatiquement trouver les fichiers corrects.

Answer 2

Il semble que les fonctions/classes que votre projet de test utilise à partir de vos projets principaux ne soient pas exportées. Si le code n'est pas exporté, rien en dehors de la DLL/exe dans laquelle réside le code ne peut le référencer. Un moyen commun que nous traitons est d'ajouter une définition au projet (dans les paramètres du projet, allez dans Propriétés de configuration -> C/C++ -> Préprocesseur, la première ligne a les définitions) appelé quelque chose comme PROJECTNAME_IMPL (assurez-vous de le faire pour les deux configurations de débogage et de libération!). Ensuite, il y a un fichier d'en-tête (appelé ProjectNameExport.h) que tout exporté comprend, qui contient quelque chose comme ce qui suit:

#ifdef PROJECTNAME_IMPL 
    #define PROJECTNAME_API __declspec(dllexport) 
#else 
    #define PROJECTNAME_API __declspec(dllimport) 
#endif 

Ensuite, lors de la définition d'une classe (par exemple):

#include "ProjectNameExport.h" 

class PROJECTNAME_API Foo 
{ 
}; 

Cette a pour résultat d'exporter la classe lorsque le fichier d'en-tête est inclus dans un fichier dans le projet, et d'importer la classe lorsque le fichier d'en-tête est inclus dans un fichier d'un autre projet (bien sûr lié au premier projet).

Answer 3

J'ajoute toujours le code à tester dans un fichier .lib statique séparé, et l'application principale EXE et les tests unitaires EXE en dépendent. Nouveau code est ajouté le projet .lib, et le support de dépendance assurer le lien EXEs sans erreurs. Vous devez vous assurer que les projets EXE peuvent trouver les en-têtes .lib, mais cela dépend de la structure de votre répertoire. Vous devez également regarder que le .lib et les EXE utilisent la même bibliothèque CRT/MFC (par exemple, lorsque vous utilisez le CRT, vous pouvez lier statiquement avec lui ou utiliser une DLL).

Je trouve que l'utilisation de bibliothèques est plus facile à gérer que l'ajout de fichiers/en-têtes à plusieurs projets. J'utilise le cadre de test Boost mais je structurerais le même, peu importe le cadre TDD.

Un bon article sur une configuration similaire se trouve ici:

http://www.codeproject.com/KB/architecture/Designing_Robust_Objects.aspx