Technologies

Java et les tests

Publié le : Auteur: vhanniet Un commentaire
5294f3d9f92ea1677e000083

mavenjenkinsjunitsonarqube

Imaginons une organisation qui se lance dans le développement Java et souhaite monter sa première plate-forme de développement Java. Que peut-on lui conseiller pour la partie tests ?

Lorsqu’on parle de test en Java un des premiers noms qui vient à l’esprit est JUnit. Puis on pense à l’intégration continue qui permet de tester la non régression au fil de l’eau, par exemple avec Maven (mais en fait Maven s’occupe surtout du build). Et enfin éventuellement à Sonar (qui s’appelle SonarQube depuis peu) pour la qualité logicielle, et à Test Director (maintenant HP Quality Center) pour la gestion de plans de tests. Et en poussant un petit peu on arrive à se souvenir qu’on pourrait faire de la gestion des exigences, par exemple avec DOORS. Ah oui, et aussi qu’il faut gérer les bugs, par exemple avec Mantis, Jira ou Bugzilla.

Wahou ! Ça fait beaucoup de sujets. Et assez différents en plus. De plus, les produits mentionnés ne sont pas spécifiques à Java (sauf JUnit mais il se décline pour d’autres technos).

Le problème posé

Je ne vais pas faire ici une liste des sujets et un comparatif des différentes solutions pour chaque sujet : ce serait trop long. Et je ne crois pas trop aux comparatifs. Pourquoi ? On ne peut comparer que ce qui est comparable et généralement les situations projet et les contextes d’entreprise sont tellement divers que les comparaisons générales sont très souvent… trop générales. Rien ne vaut un bon benchmark rapide, en commençant par préciser les cas d’usage que l’on souhaite traiter en priorité et en regardant les produits les plus utilisés sur le marché pour ces cas d’usage.
Par ailleurs, il existe de très nombreuses sources d’information sur le sujet des tests et notamment une que je trouve excellente même si elle est limitée aux solutions open source : http://www.opensourcetesting.org.

Comment choisir alors ? Il faut déjà se mettre d’accord sur les cas d’usage. Le domaine des tests ne fait pas exception : on utilise beaucoup de termes sans forcément avoir tous la même idée en tête, la même définition. L’entrée Test (informatique) de Wikipédia est intéressante, à défaut d’être parfaite, pour situer ce qu’on appelle test. Voici un petit schéma résumé qui s’en inspire pour décrire les « niveaux » de test :

NvbeauxTest

Quel que soit son niveau un test peut porter sur une exigence fonctionnelle ou non fonctionnelle (c’est indépendant du niveau). Et ce même test sera qualifié de « Test de Non régression » (TNR) s’il a déjà été passé au moins une fois avec succès et qu’on le repasse sur une nouvelle version du logiciel. TNR n’est pas un type de test en soi.

La définition de référence pour le vocabulaire des tests (en anglais) est téléchargeable sur le site de l’ISTQB. Et notons au passage qu’il existe un très sérieux Comité Français des Tests Logiciels qui propose des traductions en français de ce qu’on trouve sur le site de l’ISTQB.

Vue large

Plus généralement : un test est un examen. Il y a des donc des questions et on doit évaluer la qualité des réponses pour déterminer si le test est passé avec succès ou pas. Soyons clairs : le principal problème est de formuler les bonnes questions. L’évaluation des réponses peut être parfois un peu complexe (temps de réponse en charge par exemple) mais n’est pas un problème en soi. L’organisation du processus de test est un problème général d’organisation, important mais pas propre au test.

Par contre, en informatique, l’industrialisation des processus de test est un point critique : on cherche l’automatisation (jeux d’essai et exécution) pour augmenter la qualité (adéquation aux exigences) des programmes livrés en augmentant la fréquence des tests à budget fixé. Et ce d’autant plus que les corrections sont moins couteuses si les écarts sont trouvés en amont du cycle. Cette automatisation n’est pas toujours possible et pas toujours souhaitable — par exemple si son coût est supérieur à celui d’une non automatisation sur le même périmètre.

Comment se lancer ?

Le problème posé concerne une première plateforme Java. Comme le projet va découvrir (faute d’expérience partagée) de nombreux petits problèmes qu’il faudra résoudre, si on ne veut pas que l’industrialisation des tests soit reportée à une « vague 2 » il faut aller au plus simple.

Puisqu’il existe beaucoup d’outils pour industrialiser, le chemin le plus simple c’est quand les « bonnes » questions sont déjà formulées (parce que génériques) ou quand leur formulation est explicite. On peut donc préconiser de mettre en place :

  • Le couple Maven/Jenkins qui fera à coup sûr l’affaire pour orchestrer l’intégration continue permettant (entre autres) d’automatiser le déroulement d’une partie des tests
  • JUnit pour implémenter différents types de test aux niveaux unitaire et intégration. Deux avantages ici : JUnit est facile à brancher sur Maven (pour le build) et sur Jenkins (pour l’intégration continue), et d’autre part les tests étant développés sous forme de code on est sûr que leur contenu répond explicitement aux exigences qu’on aura exprimées (*)
  • SonarQube pour tester la conformité aux standards de développement Java : rien à faire de particulier sinon installer SonarQube et le brancher sur Jenkins. Ceci permet de rapidement traiter un premier pan des exigences non fonctionnelles. Et il sera toujours possible de raffiner plus tard.

(*) Un écueil cependant pour JUnit : comme c’est du code, ce code lui même prend du temps à écrire et est sujet à erreurs ! Voir par exemple « JUnit Anti-patterns » ou « JUnit antipatterns ».

La configuration proposée ci-dessus s’apparente au minimum qu’il faudrait mettre en place sur tout projet. Elle ne couvre qu’une partie de la maîtrise de la qualité du livrable final et notamment pas les tests Aval qui sont, finalement, ceux sur lesquels sera jugée la qualité du travail des équipes de développement par le Maître d’Ouvrage payeur.
Cependant, c’est une bonne base de départ. Moins que ça serait vraiment très très artisanal… (et néanmoins trop fréquent ;D).

Qu’en pensez-vous ?