Séparation des classes JUnit dans un package de test spécial?
J'apprends les concepts du développement piloté par les tests en lisant les articles Craftsman (click Craftsman under By Topic) recommandé dans un réponse à ma question précédente, "Exemple de projet pour apprendre JUnit et l'ingénierie logicielle appropriée" . Jusqu'à maintenant j'aime ça!
Mais maintenant, je veux m'asseoir et l'essayer moi-même. J'ai une question qui, je l'espère, n'aura besoin que d'une réponse simple.
Comment organisez-vous vos classes de test JUnit et votre code réel? Je parle principalement de la structure du package, mais tout autre concept de note serait utile aussi.
Mettez-vous des classes de test dans org.myname.project.test. * Et du code normal dans org.myname.project. *? Mettez-vous les classes de test juste à côté des classes normales? Préférez-vous préfixer les noms de classe avec Test plutôt que de les suffixer?
Je sais que cela semble être le genre de chose dont je ne devrais pas m'inquiéter si tôt, mais je suis une personne très centrée sur l'organisation. Je suis presque le genre de personne qui passe plus de temps à trouver des méthodes pour garder une trace de ce qu'il faut faire, plutôt que de réellement faire avancer les choses.
Et j'ai un projet qui est actuellement soigneusement divisé en packages, mais le projet est devenu un gâchis. Au lieu d'essayer de tout refactoriser et d'écrire des tests, je veux recommencer, les tests d'abord et avant tout. Mais je dois d'abord savoir où vont mes tests.
edit: J'ai totalement oublié Maven, mais il semble que la majorité d'entre vous l'utilise! Dans le passé, j'ai eu un cas d'utilisation spécifique où Maven est complètement tombé en panne sur moi mais Ant m'a donné la flexibilité dont j'avais besoin, alors je me suis retrouvé attaché à Ant, mais je pense peut-être que je ne faisais que la mauvaise approche. Je pense que je vais donner à Maven un nouvel essai car il semble que cela ira bien avec le développement piloté par les tests.
Je préfère placer les classes de test dans le même package que les classes de projet qu'ils testent, mais dans un répertoire physique différent, comme:
myproject/src/com/foo/Bar.Java
myproject/test/com/foo/BarTest.Java
Dans un projet Maven, cela ressemblerait à ceci:
myproject/src/main/Java/com/foo/Bar.Java
myproject/src/test/Java/com/foo/BarTest.Java
Le point principal est que mes classes de test peuvent accéder (et tester!) Aux classes et aux membres de portée de package.
Comme le montre l'exemple ci-dessus, mes classes de test ont le nom de la classe testée plus Test comme suffixe. Cela permet de les trouver rapidement - ce n'est pas très drôle d'essayer de rechercher parmi quelques centaines de classes de test, dont le nom commence par Test...
pdate inspiré par le commentaire de @ Ricket: de cette façon, les classes de test apparaissent (généralement) juste après leur copain testé dans une liste alphabétique par projet des noms de classe. (C'est drôle que j'en profite de jour en jour, sans avoir consciemment réalisé comment ...)
pdate2: Beaucoup de développeurs (y compris moi-même) comme Maven, mais il semble y en avoir au moins autant qui ne le font pas. À mon humble avis, il est très utile pour les projets "grand public" Java (je mettrais environ 90% des projets dans cette catégorie ... mais les 10% restants sont encore une minorité importante). C'est facile à utiliser si l'on peut accepter les conventions de Maven, mais sinon, cela rend la vie une lutte misérable. n'a jamais utilisé Ant, ne peut pas comparer les deux.) Une chose est sûre: cela fait des tests unitaires (et d'intégration) une étape naturelle et de première classe dans le processus, ce qui aide les développeurs à adopter cette pratique essentielle.
J'ai mis mes classes de test dans le même package que ce qu'elles testent mais dans un dossier ou un projet source différent. L'organisation de mon code de test de cette façon me permet de le compiler et de le conditionner facilement de façon à ce que les fichiers jar de production ne contiennent pas de code de test. Il permet également au code de test d'accéder aux champs et méthodes privés du package.
J'utilise Maven . La structure que Maven promeut est: -
src/main/Java/org/myname/project/MyClass.Java
src/test/Java/org/myname/project/TestMyClass.Java
c'est-à-dire qu'une classe de test avec Test précédé du nom de la classe sous test est dans une structure de répertoire parallèle au test principal.
Un avantage d'avoir les classes de test dans le même package (pas nécessairement le répertoire) est que vous pouvez utiliser les méthodes de portée de package pour inspecter ou injecter des objets de test fictifs.