Discussion :

[xxiemeciel]

Bonjour,

Ceci est une question assez generique mais en meme temps assez specifique j'espere donc l'avoir mise au bon endroit.

Je suis en train de faire des recherches pour developer une convention de tests unitaire pour mon entreprise. Nous travaillons en C++ et avons decidé d'utiliser CppUnit mais ma question peux etre valable pour d'autre langages.

nous avons notre arbre des sources et nous nous demandons si nous devrions rajouter un repertoire TEST dans chaque sous repertoire de notre arbre des sources sachant qu'il faudra au moment du release extraire tout ces repertoires

ou alors creer un arbre de source pour les tests, parallele a notre arbre des sources et contenant tout les tests unitaires dans une hierarchie similaire. Au moment du release il suffit d'exclure l'Arbre des tests.

Quelle stratégie vous semble la plus appropriées , ou si vous avez d'autre stratégie a proposé je reste attentif.

Cordialement
Vincent

[Strab]

Dans tous les projets que j'ai vus, ainsi que dans celui que je suis en train de réaliser, un arbre parallèle dans un répertoire test est utilisé (et tout ces projets sont des outils de tests unitaires...).
La principale raison est celle que tu donnes, plus simple à archiver lors des releases.

Il existe un inconvénient dans le cas du Java (et d'autres langages ?) : certaines classes et méthodes ne sont visibles que depuis leur répertoire (c'est la notion de package en Java). Mais je ne crois pas que cela concerne le C++ (je ne connais que le C), et ce n'est pas résolu par l' autre solution que tu proposes(ça l'est en plaçant les tests dans le même répertoire que les sources).

De plus, une arborescence parallèle est plus facile à parcourir par un lanceur automatique des tests.

En bref, je ne vois aucun avantage aux multiples répertoires tests, et j'en vois à l'arborescence parallèle.
Je veux bien d'autres avis, car je très concerné par cette question.

[xxiemeciel]

Merci de ta reponse,

je suis assez d"Accord avec toi. Cependant d'autre personne dans ma compagnie prefere l'option du repertoire de test dans chaque sous repertoire de l'arbre des sources.

Nous pensons aussi utiliser les tests dans le post build de chaque compilation. Ils ont alors pensé qu'il serais plus pratique d'incorporer directement les codes de test.

Une autre raison est de donner les tests aux utilisateurs pour tester l'ordinateur et l'environement avant l'instalation de l'application.

Je ferais savoir lorsqu'une decision definitive aura été adopté.

Vincent

[Nip]

j'espere donc l'avoir mise au bon endroit.

Il y a une section dediee a tout ce qui est methodologie, c'est la qu'est la place de ta question : Modélisation, Méthodes, Architectures, Tests...

Effectivement choisir l'emplacement des tests peut etre problematique; il y a plusieurs solutions:
1-placer le code des tests dans des methodes de la classe a tester: ca alourdit la code, pose probleme si le test doit connaitre plusieurs classes sans parler du probleme de securite (correspond non seulement a une documentation du code mais aussi laisse des points d'entree sur les classes testees)
2-placer le code des tests dans le meme composant et augmenter la visibilite des membres ->mauvais pour l'encapsulation (si t'as une approche OO)

Par contre ces methodes ont l'avantage de permettre une disponbilite totale des tests.

3-Le code des tests dans un composant different: Pas de deploiement des tests et controle total des tests pour le chef de projet (une fois le test ecrit plus personne n'y accede et lors des modifs ulterieures sur les classes a tester, les tests doivent a nouveau passer sans etre modifies); par contre on perd la disponibilite des tests.
Je sais qu'en .Net, je passe outre le probleme de la visibilite des membres par la reflexion, apres en C++ je ne sais pas trop. En tout cas je prefere cette derniere pratique

[xxiemeciel]

J'ai eu un peu de mal a retrouver les messages

Merci pour les reponses

Vincent

[tipiak]

de mémoire de ce que j'ai vu sous JUnit en java c'est :

2 arbres distinct :
1 arbre de code et un arbre de tests

mais une seule arborescence de package ....

donc d'un point de vu stockage c'est bien séparé
et dans l'IDE tu n'as qu'un seul arbre :
gerne le package composantX sera composé de :
-VueCOmposantX
-LogicComposantX
-testVueComposantX
-TestLogicCOmposantX
....

ce qui passe bien avec Junit car l'intégration dans les IDE te permet de faire un p'tit clique droit sur le composant => run tests composant...

et pour l'archivage et le packaging de livraison bah tu sélectionne que l'arbre dont tu as besoin...

[fkorbi]

Bonjour, je me trouve dans la meme situation que la tienne "xxiemeciel", je veux integrer mon travail de test dans une arbre independante de source ( c a d arbre //), le probleme rencontré est au niveau du "makefile" du projet de test plus precisement au niveau de .pro (le générateur des makefile).

Description de probleme:

/
|--- [SRC]
|--- [H]
|--- [SRCTEST]
|--- [HTEST]

fichier a testé: source.c (SRC)
fichier de test: testsource.c (SRCTEST)

/************************************
********** testsource.c **************
************************************/
#include "source.h"
...
...

Les methodes et les variables de "source.c" ne sont pas visible ds "testsource.c"

NB: quand jai fais les premiers essais avec CppUnit, les fichiers sources ainsi que les fichiers de test se trouvent dans le meme repertoire, donc jai pas eu un probleme de ce genre.

Jéspére que jai bien explqué

Merci pour l'aide