Organisation des tests JUnit en projets

Question

Selon vous, quelles sont les meilleures pratiques pour organiser des tests JUnit dans un projet et pourquoi? Par exemple, gardez-vous vos tests à côté des cours qu’ils testent? Les mettez-vous dans une structure de paquet séparée mais parallèle? Utilisez-vous une stratégie d'organisation totalement différente?

Answer 1

J'utilise une structure de package séparée mais parallèle pour plusieurs raisons.

1. Il maintient les tests organisés de la même manière que le code de l'application.
2. Je peux facilement construire uniquement les fichiers d'application pour la distribution.
3. Le code de test a toujours accès à mon code d'application.
4. Ce n'est pas aussi encombré que d'avoir un code de test mélangé avec un code d'application.

Answer 2

Je mets mes tests dans une structure de package séparée mais similaire / parallèle. C’est comme ça que Maven aime les choses et que cela fonctionne aussi bien avec les IDE. Je l’aime bien de cette façon car je n’ai pas mélangé mon code de test avec mon code d’application, mais je peux toujours accéder à des éléments de paquet privé pour se moquer et vérifier l’état.

Answer 3

Suffit d'utiliser Maven. Avec maven, vous pouvez créer une structure par défaut pour votre projet:

mvn archetype:create -DgroupId=com.yoyodyne -DartifactId=UberApp

Cela va créer Maven du répertoire standard de mise en page contenant l'espace pour les tests unitaires ainsi que votre projet principal. À l'aide de maven, vous pouvez ensuite exécuter les tests unitaires sans emballage, pour un pot, et vous pouvez construire un bocal qui contient votre application. Vous pouvez également avoir différents chemins de classe et les différentes dépendances pour les exécuter, tester et moment de la compilation.

Je trouve ça très inquiétant de constater que si peu de gens autour d'ici sont en fait à l'aide de Maven (ou au moins la Fourmi, bien que je préfère Maven pour la gestion des dépendances.)

Answer 4

Je respecte le projet Maven de la structure, même si je n'ai pas utiliser maven sur un projet, tout simplement parce que je m'y suis habitué. La meilleure pratique consiste à utiliser une source distincte du dossier, qui respecte la même structure de paquet en tant que votre principale source de dossier.

Votre test de sources spécifiques (utils que vous seul, pour être utilisé dans les tests) doit être mis là-bas et si vous avez l'intention de les utiliser avec l'app runtime code puis le déplacer dans le dossier source principal. L'idée est de dissocier, comme vous factoriser l'efficacité par la séparation de la persistance et de contrôle pour les anciens.

Answer 5

comme le dit le lézard,

il est utile d'avoir une structure parallèle pour que 1) je puisse envoyer un fichier src.zip ou src.tar.gz et laisser de côté les tests unitaires ne modifie que les tests unitaires

"Désavantage"
Vous ne pouvez pas sceller votre fichier JAR si les tests source et unitaire se trouvent dans le même package (c’est-à-dire que vous devez supprimer les tests unitaires avant de préparer votre .JAR et de le sceller).