Où devrais-je placer mes tests JUnit?

Question

J'ai deux questions sur l'organisation des tests unitaires.

1. Dois-je mettre le test dans le même package que la classe testée ou puis-je organiser des tests dans différents packages?

   Par exemple, si j'ai des validités et des autres tests, est-il correct de les scinder en différents packages, même s'ils appartiennent à la même classe?

2. Qu'en est-il des classes simulées et tronquées? Dois-je les séparer des paquets ne contenant que des tests, ou les mettre ensemble?

Answer 1

La façon dont nous traitons nos cas de tests JUnit consiste à les placer dans le même package, mais dans un répertoire racine différent. Puisque nous utilisons Maven, nous utilisons simplement les emplacements standard, ce qui rend la structure similaire à celle-ci.

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

Évidemment, la structure ne se résume pas à cela, mais cela nous permet de construire les tests séparément du code principal, tout en continuant d'accéder aux classes protégées, etc. En ce qui concerne différents types de tests, ceci est très subjectif. Lorsque nous avons commencé nos tests (qui ont malheureusement commencé après le développement), j'ai essayé de garder les choses assez isolées. Malheureusement, le cauchemar est vite devenu cauchemardesque lorsque nous sommes arrivés au stade des 500 essais et plus. J'ai depuis essayé de faire plus de consolidation. Cela a conduit à des quantités réduites de code à maintenir. Comme je l'ai dit, cependant, c'est très subjectif.

En ce qui concerne le code de test uniquement, nous le conservons dans un package com.foo.test distinct qui réside uniquement dans l'arborescence src / test / java . <. / p>

Answer 2

Moi aussi, j'ai tendance à placer mes tests dans le même package, mais dans un répertoire racine différent. Cela me permet de tester des classes de paquetage privé ou d'accéder à des classes de paquetage privé tout en testant autre chose dans le paquetage. Ils sont conservés dans une arborescence de répertoires distincte pour permettre leur exclusion du résultat déployé (en particulier pour garantir que le code de test ne soit pas accidentellement entré dans le code de production). Cependant, ce qui compte le plus, c’est ce qui convient à votre situation.

En ce qui concerne le nombre de classes de test par classe de production, la théorie que j'ai vue est que vous écrivez une classe de test par unité, c'est-à-dire par structure d'installation. Dans de nombreux cas, c’est identique (ou assez proche) à une classe de tests par classe de production, mais j’ai parfois écrit plus de classes de tests (en particulier les tests d’égalité ont tendance à être séparés) pour une classe de production donnée, et parfois une classe de tests de pour un groupe de classes de production (liées) (par exemple, pour tester le modèle de stratégie).

La plupart du temps, je ne m'inquiète pas trop de la théorie, mais retravaillez les tests selon les besoins pour limiter au maximum les doubles emplois.

Answer 3

Les classes de test doivent plutôt être dans différents packages, il est plus facile de les séparer du code de production lorsque vous le mettez en package pour publication. Je garde généralement beaucoup de fluff de test dans ces packages, toutes sortes de simulacres, configurations, scénarios… Mais lorsque vous construisez, tout ne se passe pas bien. Dans certaines situations, il est judicieux de conserver vos tests même dans différents projets. Dépend.

Answer 4

En conservant le même package, vous pouvez utiliser la visibilité privée du package pour le code destiné à être accessible via le test uniquement.

En ce qui concerne l’utilisation de répertoires racine distincts, c’est une bonne pratique. C'est également un avantage pour nous, puisque nous utilisons IDEA, IDEA reconnaît que le code de production ne peut pas référencer le code de test.

Pour ce qui est de les séparer, il existe un grand pouvoir d’avoir une et une seule classe de tests par classe de production au niveau de l’unité. Bien sûr, certaines classes sont créées en production dans le cadre du refactoring sans aucune classe de test, ce qui est bien, mais lorsque vous voulez savoir quel test teste une classe donnée, la convention suivante indique que ClassNameTest est le test de ClassName. est très utile.

TestNG est cependant beaucoup plus convivial que JUnit avec ce paradigme.