mai
2009
Un article de Philippe Vialatte
Suite à une petite discussion sur un forum externe a DVP (celui d’un des livres que je suis en train de lire), je me pose un peu des questions sur les pratiques de tests(unitaires ou autres).
De mes différentes expériences, un a grosso modo deux choix, avec une variante :
- Stocker les tests dans des projets spécifiques :
Dans ce cas, que j’utilise en général, on va ajouter à la solution un (ou plusieurs, dan le cas ou on veut séparer les tests unitaires et les tests d’intégration) projet, dont le contenu sera uniquement composé de tests. Par exemple, ma solution Solution1 va avoir un projet Solution1.UnitTests et un projet Solution1.IntegrationTests. Cette configuration va me permettre de localiser facilement les tests, de configurer facilement un serveur d’intégration continue pour lancer le(s) projet(s) de test.
- Stocker les tests dans les projets du code testé:
L’avantage principal de cette méthode est de pouvoir accéder aux propriétés internes, voire privées (si le test est dans la classe) de la classe en cours de test. Cela permets aussi de voir facilement le code testé, le code étant dans le même fichier, ou dans le même répertoire.
Personnellement, je suis plutôt fermement convaincu que la première méthode est la meilleure.
En premier lieu, les tests unitaires doivent être des tests de « boite noire » , donc des tests qui en s’occupent pas du contenu réel du code testé, mais des entrées et sorites. Dans le cas contraire, les tests en savent souvent trop sur le code testé, et finissent par devenir fragiles et constituent une résistance au changement. Par conséquent, je considère l’avantage principale du stockage de tests dans le même projet comme potentiellement dangereux
Ensuite, imaginons que, pour des raisons d’extensivité des tests, on veuille explicitement tester un membre interne d’une classe donnée. Dans ce cas, il suffit d’ajouter l’attribut InternalsVisibleTo pour contourner le problème.
Enfin, cela permets de ne pas livrer de code qui ne sera pas utilisé par les clients finaux.
Alors, à ca, on m’à répondu que c’était « plus simple » de mettre le code de test dans les mêmes projets/fichiers.mais je ne suis pas tout à fait d’accord, d’ou ma question, qu’en pensez-vous ???
4 Commentaires + Ajouter un commentaire
Articles récents
Archives
- janvier 2014
- septembre 2013
- août 2013
- mai 2013
- avril 2013
- janvier 2013
- août 2012
- juin 2012
- mai 2012
- avril 2012
- mars 2012
- novembre 2011
- septembre 2011
- août 2011
- juillet 2011
- juin 2011
- mai 2011
- avril 2011
- février 2011
- janvier 2011
- novembre 2010
- octobre 2010
- septembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
En maven, tu es obligé de séparer les tests et le code. Si tu ne connais pas maven, c’est un projet open source pour gérer le cycle de développement d’un projet Java (grosso modo, si tu défini ton projet en respectant les règles de maven, tu peux compiler ton projet, lancer les tests, générer le programme, etc…).
De plus, en maven, tu as des répertoires différents pour les fichiers de configurations. Cela permet d’avoir un fichier dans ton projet qui pointe sur ta base de développement, et ton code de test a son propre fichier de configuration qui pointera vers la base de test.
Pour moi, je sépare toujours mes tests du reste du projet. Comme cela, quand je compile le code du projet sans le code de test avant de livrer, si le projet fait référence à un teste, il y a une erreur de compilation.
En tant que dev .NET, tous mes tests sont systématiquement dans des projets séparé. Le nom du projet est le même que celui qui contient les classes à tester mais suffixé par Test. la même règle s’applique aux fichiers qui contiennent le code de test. En gros ça donne un projet de test par librairie et dans ces projets de tests, un fichier par classe à tester.
Quant au problème d’accéder aux membres interne ce n’est clairement pas un problème avec la méthode que tu as signalé. Pour les membres privés VS permet de générer des classes proxy qui permettent d’y accéder.
J’ai oublié de préciser que j’étais contre le fait de le mettre dans le même fichier, il ne faut pas tomber dans l’extrémité inverse non plus. Souvent, le bon compromis est au milieu !
Je ne fais pas de .Net mais je pense qu’on a des problèmes similaires en Java.
Tu as bien exposé les avantages/inconvénients des deux options.
En java, on peut même avoir 3 solutions :
– différents projets
– même projet mais différents dossiers sources
– même projet, même dossier source
Personnellement, j’ai choisi la dernière solution car j’ai pris l’habitude de créer une classe de Test de même nom que la classe testé mais suffixé par Test.
L’intérêt du code de test avec le code testé, c’est qu’on a tout sous la main. Pour ta remarque de boite noire, on peut très bien tester uniquement les entrées/sorties mais il faut s’y contraindre c’est vrai.
Si le code de test est loin du code testé (dans un autre projet), ne risque ton pas d’oublier de le faire évoluer également ?
Pour ton argument de ne pas livrer le code de test, j’ai une tâche ant qui ne zip par les fichier se terminant pas Test (d’où ma convention)
J’admets cependant que la solution que je pratique va bien pour des tests unitaires.
Pour les tests d’intégrations, je ne ferai pas de commentaires …