Séparation des classes JUnit dans un package de test spécial?

Question

Je suis en train d'apprendre les concepts de Développement Piloté par les tests grâce à la lecture de l' Artisan articles (cliquez sur Artisan sous Par Sujet) a recommandé, dans une réponse à ma question précédente, "Exemple de projet pour l'apprentissage de JUnit et le bon génie logiciel". Je l'aime tellement loin!

Mais maintenant, je veux m'asseoir et d'essayer moi-même. J'ai une question qui je l'espère n'aura besoin que d'une simple réponse.

Comment organisez-vous votre test JUnit classes et de votre code? Je parle principalement sur la structure du package, mais d'autres concepts de la note serait utile aussi.

Ne vous mettez classes de test dans org.myname.projet.les tests.* et de code dans org.myname.projet.*? Ne vous mettez les classes de test, tout à côté des classes normales? Préférez-vous pour préfixer les noms de classe avec le Test plutôt que de suffixe?

Je sais que cela semble être le genre de chose que je ne devriez pas vous soucier de si tôt, mais je suis une organisation centrée sur la personne. Je suis presque le genre de personne qui passe plus de temps à essayer de comprendre les méthodes pour garder une trace de ce qui est à faire, plutôt que de réellement faire avancer les choses.

Et j'ai un projet qui est actuellement parfaitement divisés en paquets, mais le projet est devenu un gâchis. Au lieu d'essayer de revoir tout et écrire des tests, j'ai envie de repartir de zéro, les tests et tout et tout. Mais d'abord, j'ai besoin de savoir où mes tests.

---

edit: j'ai totalement oublié de Maven, mais il semble qu'une majorité d'entre vous l'utilisez! Dans le passé j'ai eu un cas d'utilisation spécifiques où Maven complètement craqué sur moi, mais la Fourmi m'a donné la flexibilité dont j'avais besoin, je me suis donc retrouvé attaché à la Fourmi, mais je pense peut-être que je viens de prendre la mauvaise approche. Je pense que je vais donner Maven, essayez un autre parce qu'il sonne comme il va bien avec le test-driven development.

Answer 1

Je préfère mettre les classes de test dans le même package que le projet des classes à tester, mais dans un autre répertoire physique, comme:

myproject/src/com/foo/Bar.java
myproject/test/com/foo/BarTest.java

Dans un projet Maven, il devrait ressembler à ceci:

myproject/src/main/java/com/foo/Bar.java
myproject/src/test/java/com/foo/BarTest.java

Le point principal, c'est que mon test de classes d'accès (et de tester!) paquet-champ d'application les classes et les membres.

Comme l'exemple ci-dessus montre, mon test de classes ont le nom de la classe testée plus Test comme un suffixe. Cette aide à trouver rapidement - il n'est pas très marrant à essayer de chercher parmi une centaine de classes de test, dont le nom commence par Test...

Mise à jour de inspirée par @Ricket commentaire: cette façon de classes de test (généralement) de vous présenter tout de suite après leur testé copain dans un projet de sage-liste alphabétique des noms de classe. (C'est marrant que je suis bénéficiant de ce jour par jour, sans l'avoir consciemment réalisé combien...)

Update2: beaucoup de développeurs (dont moi-même) comme Maven, mais il semble y avoir au moins que beaucoup de ceux qui n'en ont pas. À mon humble avis il est très utile pour "mainstream" des projets Java (j'en ai mis environ 90% des projets de cette catégorie... mais l'autre 10% est toujours une minorité non négligeable). Il est facile à utiliser si l'on peut accepter les conventions de Maven; toutefois, si non, il vous rend la vie misérable de la lutte. Maven semble être difficile à comprendre pour beaucoup de gens socialisé sur Ant, comme apparemment il exige une manière de penser très différente. (Moi-même, n'ayant jamais utilisé de Fourmi, on ne peut pas comparer les deux.) Une chose est sûre: il fait de l'unité (et de l'intégration), l'expérimentation d'un naturel, de première classe de l'étape dans le processus, ce qui aide les développeurs à adopter cette pratique essentielle.

Answer 2

Je mets mes classes de test dans le même package que ce qu'elles testent, mais dans un dossier ou projet source différent . En organisant mon code de test de cette manière, je peux facilement le compiler et le conditionner séparément afin que les fichiers jar de production ne contiennent pas de code de test. Il permet également au code de test d'accéder aux méthodes et champs privés du package.

Answer 3

J'utilise Maven . La structure que Maven promeut est la suivante: -

 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ée du nom de la classe sous test se trouve dans une structure de répertoire parallèle au test principal.

L'un des avantages des classes de test dans le même package (pas nécessairement l'annuaire) est que vous pouvez exploiter les méthodes de la portée du package pour inspecter ou injecter des objets de test fictif.