Talk A Little About What I Like

Profiter des dernières nouveautés de JUnit 4 depuis Spring est possible mais attention à leur utilisation conjointe depuis Eclipse.

En effet si vous vous contentez d’inclure la librairie Eclipse JUnit prédéfinie (via le menu Propriétés du projet puis Java Build Path | Libraries | Add Library | Junit) et que vous incluez l’annotation @RunWith(SpringJUnit4ClassRunner.class) à la déclaration de votre classe de test, il y a de fortes chances pour que vous tombiez sur les erreurs de compilation suivantes :

The project was not built since its build path is incomplete. Cannot find the class file for org.junit.internal.runners.JUnit4ClassRunner.
The type org.junit.internal.runners.JUnit4ClassRunner cannot be resolved.

ce problème est lié à la version de JUnit embarquée par défaut dans les distributions d’Eclipse de version inférieures à 3.3.

Pour pallier ce petit soucis, il faut utiliser une version de JUnit supérieur ou égale à 4.4, et l’ajouter explicitement dans le projet.

Il est particulièrement stressant lorsqu’on est en plein travail sous Eclipse de voir l’application se fermer sans aucun avertissement et bien sûr sans sauvegarder les modifications en cours. Ce phénomène est lié à la saturation de la mémoire allouée au fonctionnement du logiciel et plus particulièrement à la taille de la mémoire permanente (PermGen) très sollicitée par le chargement des classes.

L’une des solutions est de paramétrer la jvm de lancement d’Eclipse via l’argument -vmargs de l’exécutable. Ci-dessous un exemple de paramétrage, à adapter évidemment en fonction des besoins et de la taille mémoire disponible sur la machine hôte :

-vmargs -Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

Enfin le plugin qu’il manquait pour travailler efficacement avec le couple Eclipse/Maven. M2WTP permet de profiter pleinement des facilités de développement sous WTP (compilation à la volée, gestion des déploiement et débuggage) tout en gérant les dépendance de l’application avec le plugin m2eclipse (cf. ancien post). Seule une petite manipulation préalable est nécessaire pour éviter de se marcher sur les pieds (suppression des dépendances Maven dans le buildpath) et le tour est joué.

Les étapes nécessaires pour travailler tranquillement en j2ee sous Eclipse sont donc :

• ajouter la variable M2_REPO dans le classpath
• création d’un projet web dynamique en précisant les répertoires src/main/webapp et src/main/java dans les champs adéquats pour se conformer à la structure Maven
• ajout de la nature Maven
• activation de m2wtp
• ajout des dépendances initiales

Précisons que ce plugin nous est proposé par Google Code et n’est qu’en version de développement, donc ce n’est qu’un début et il est plutôt prometteur. Il reste quand même quelques dysfonctionnements plutôt crispants comme le fait que de temps en temps les librairies se retrouvent en double dans le classpath. Dans ce cas le seul moyen de corriger le problème est de modifier à la main le fichier de configuration org.eclipse.wst.common.component dans le .settings du projet. Je pense que ce comportement est lié au fait de ne pas effectuer les manipulations citées ci-dessus dans le bon ordre, mais ça reste rageant.

N’hésitez pas à proposer d’autres méthodes plus pratiques si vous en connaissez, je suis preneur. Le plugin Eclipse de Maven est censé fournir le même service mais je n’ai pas réussi à le faire fonctionner, et je ne suis pas le seul, donc je l’ai écarté pour l’instant.
libcopy est un plugin équivalent mais à priori moins abouti dans le sens où il créé des redondances de librairies dans le build path en ajoutant des liens vers les librairies Maven.

Une mise à jour attendue corrigeant de nombreux bugs (don ceux référencés dans le billet précédent sur le sujet) et apportant entre autres le wizard de création de projet maven permet de choisir l’arborescence à créer par défaut (main, test, resources,…), les propriétés du projet (version, group id,…) ainsi qu’une première liste de dépendances.

Déjà disponible depuis le début de l’année, la dernière versionde JUnit apporte son lot de nouveautés et permet de répondre en partie à la concurrence (TestNG pour ne pas le citer). Il était donc temps que je m’y intéresse d’un peu plus près.

Je ne vais pas faire une n-ième description des nouvelles fonctionnalités apportées par cette version mais plutôt apporter mon point de vue sur certaines d’entre elles.

• héritage et conventions de nommage : les classes de tests n’ont plus besoin d’hériter de TestCase et les méthode de tests peuvent avoir un nom quelconque (les annotations remplacent la convention)
  un point sur lequel cette avancée est indéniablement positive, c’est le respect des limites de visibilité. Je ne pense pas être le seul à avoir été obligé d’étendre la visibilité d’une méthode ou d’une classe pour pouvoir la tester à partir d’un TestCase qui ne peut pas y avoir accès autrement, bien que ce type d’erreur puisse également être la conséquence d’une mauvaise conception.Cependant, même si cela s’avère évidemment plus pratique a l’usage, le fait de pouvoir intégrer les méthodes de tests dans les classes testées présente à mon sens 2 risques de mauvaise pratique :
  • la surcharge des classes testées avec les méthodes de test qui ne sont plus vraiment métier mais plutôt techniques, pouvant en outre mener à des classes de taille conséquente (y compris une fois compilées) dans lesquelles il devient difficile de s’y retrouver, d’autant qu’il ne suffit plus de filter sur les noms de méthodes mais sur les annotations
  • la séparation physique des sources entre les classes utiles et les classes de test. Le code s’en trouve moins clairement organisé et je ne sais pas comment des outils tels que Maven prennent cette possibilité en considération

• récupération d’exceptions : une simple annotation permet de préciser les exceptions attendues par un test
  le fait d’éviter les blocs try - catch autour des retour d’exceptions à tester est évidemment un point fort de la nouvelle version, permettant d’avoir un code moins surchargé
• timeout : possibilité de spécifier une durée maximum pour l’exécution d’un test
  Bien que cette fonctionnalité puisse être attirante, d’autant qu’elle est extrêmement facile à utiliser, il me semble qu’à part quelques rares cas ce type de tests doit être intégré à une vraie campagne de tests de performances et sorte du domaine des tests unitaires à proprement parler. En outre rappelons que pour des raisons de fiabilité des résultats, les valeurs testées n’auront de sens que pour des durées suffisamment longues, la machine virtuelle n’étant pas un environnement d’exécution temps réel adéquat, ainsi que la plateforme d’exécution de tests en général.
• fixtures : possibilité d’exécuter des méthodes avant (après) une série de tests ou avant (après) chaque méthode de test
  une terminologie plus claire et un meilleure contrôle sur les décorateurs de tests ne peuvent qu’apporter un meilleur contrôle sur le déroulement des tests ;o)
• paramétrage des tests : un test peut être exécuté plusieurs fois en utilisant des variables dont les différentes valeurs sont données par un fournisseur
  indéniablement une fonctionnalité indispensable permettant d’éviter la duplication de code. Attention toutefois à bien garder à l’esprit qu’il s’agit d’une annotation de niveau classe dont toutes les méthodes de test seront exécutées autant de fois qu’il y aura de tuples de paramètres différents. C’est là une forte contrainte qui ne permet pas par exemple de regrouper toutes les méthodes de tests liées dans une même classe, même si il est possible pour ce faire de passer par les suites (cf. point suivant). En outre, si l’un des paramètres se trouve être un tableau, il faut qu’il contienne des objets de type non primitif.
• groupes ou suites : regrouper les tests sémantiquement
  Equivalent des TestSuite utilisées dans les version précédentes de JUnit

Globalement cette version représente une avancée majeure dans l’exécution des tests via JUnit, avec malgré tout certaines améliorations encore attendues comme la dépendance entre les méthodes ou l’exécution de tests en parallèle proposées par TestNG, ainsi qu’une documentation plus etoffée (en dehors de la javadoc) … mais tout est encore faisable.

Liens utiles :
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm

Comme je suis dans l’ensemble plutôt un adepte du tout-souris, et certainement très paresseux, j’utilise dès que possible des interfaces graphiques (j’en connais qui développement sous vi en mode console, mais je les laisse s’amuser sans moi).

C’est donc tout naturellement que j’ai installé le plugin maven 2 sur Eclipse et globalement j’en suis content. Un clic droit sur un projet permet en quelques secondes d’ajouter la nature maven au projet, ce qui a pour effet de créer un pom par défaut et d’ajouter une entrée Maven2 dans les librairies eclipse.

Mais la fonctionnalité la plus fun est certainement l’accès en temps réel au repository maven via une boîte de dialogue qui s’ouvre lorsqu’on passe par le menu contextuel ‘add dependency’. Elle fonctionne sur le même principe que la recherche en local d’une librairie java et permet l’utilisation du caractère générique *. Il suffit d’entrer quelques caractères dans la zone de texte pour voir apparaître une liste d’artefacts correspondants à la recherche. Le reste se fait tout seul : modification du pom, téléchargement du jar à partir du repository et ajout dans les librairies du projet, c’est beau !

Autre point fort, les contextes d’exécution Eclipse qui permettent de définir en quelques clics des configurations de lancement de maven en précisant des phases ou des goals particuliers qui peuvent ensuite être directement exécutés via le menu ‘External tools’ de l’environnement de développement. Il est en outre possible de faire exécuter ces tâches automatiquement lors d’un build du projet, que demander de plus ?

Comme j’essaye d’être objectif, je me dois quand même d’ajouter une ou deux petites ombres au tableau :

• le fait que le plugin ne fonctionne pas systématiquement dès le début, en particulier si l’on n’a jamais exécuté maven en ligne de commande, voir http://jira.codehaus.org/browse/MNGECLIPSE-124
  
• une certaine frustration qui peut se faire sentir lorsqu’on sélectionne directement un artefact et non l’une de ses versions (il suffit simplement de dérouler la liste correspondant à l’artefact)
• des soucis de rafraichissement de la liste des artefacts dans la boîte de recherche si on les installe à la main dans le repository local
• des problèmes de raffraichissement d’index dûs au fait que certains fichiers ne peuvent pas être supprimés dans le répertoire de métadonnées du plugin, ce qui a pour conséquence l’impossibilité d’utiliser la fenêtre de recherche des artefacts. Je n’ai pas trouvé la solution à ce dysfonctionnement à part la suppression à la main et un arrêt-relance d’Eclipse

gageons que ces petits tracas ne soient que temporaires et qu’une prochaine version les verra disparaître, la version testée étant la 0.0.9.

Alors voilà, je fais triomphalement mon entrée dans le monde du blogging (si si j’en entends qui applaudissent au fond de la salle), il n’y a pas de raison pour que je ne puisse pas moi aussi raconter ma vie qui j’en suis certain passionne déjà le monde entier.

Plus sérieusement, si jamais quelqu’un d’autre que moi et ma famille (que j’obligerai bien évidemment à partir d’aujourd’hui à aller consulter mon site tous les jours et à m’en faire un résumé par écrit) consulte par hasard ces pages, je veux juste le prévenir de ce qu’il risque d’y trouver.

Je n’ai pas ouvert un compte sur blogger pour en faire un journal intime ou poluer les résultats des moteurs de recherche mais pour m’en servir comme outil de travail et comme support de mémoire (la mienne étant défaillante et mal entretenue). Le fait qu’il soit public n’est pas forcément une volonté forte de ma part mais permettra éventuellement aux personnes que certains sujets intéressent de m’apporter leur contribution, leurs avis et leurs corrections.

Les sujets abordés seront essentiellement (voire exclusivement) en rapport avec l’informatique puisque c’est mon domaine de prédilection, mais il se peut que pour diverses raisons je me permette quelques écarts de conduite.

Si vous pensez que certaines informations pourraient m’intéresser ou enrichir utilement ce site, n’hésitez pas à me le faire savoir par mail.

Voilà, si quelqu’un s’oppose à cette idée, qu’il parle maintenant ou se taise à jamais …. personne ? sûrs ? bon je clique alors …