JTest pour le contrôle qualité du code Java

1.  Problématique auquel répond cet outil

De 1965 à 1995, en 30 ans le volume de chaque logiciel a été multiplié par 100, alors que la productivité des développeurs n’augmentait que d’un facteur 3. C’est la crise du logiciel. Personne ne sait aujourd’hui créer de logiciel sans défaut ! La validation de Windows 2000 avait fait appel à 600 000 bêtas testeurs, il restait pourtant au lancement de sa commercialisation 63 000 problèmes potentiels dans le code, dont 28 000 sont réels. Un logiciel commercial type contient entre 20 et 30 bogues pour mille lignes !

Le coût de développement d’un logiciel peut être estimé, très globalement, à 100 € par instruction. A ce coût, il faut ajouter pour chaque instruction 2 000 € de maintenance !

La cause principale de bogues semble bien être l’insuffisante des tests. Des tests bien conduits permettraient de réduire considérable la facture. Il existe des procédures de tests dans les entreprises, mais les tests ne sont pas assez exhaustifs et les outils demeurent plutôt primitifs.

« Des outils de tests standardisés, des scripts, des données de référence, des évaluations associés à un processus de certification rigoureux aurait un impact beaucoup plus large sur les insuffisances constatées actuellement. » (National Institue of Standards & Technology, juin 2002)

JTest est un outil développé par Parasoft qui répond à cette problématique, il propose un processus d’automatisation des tests sur le code JavaLangage de développement très populaire !. Il analyse le code source d’un projet Java en lui appliquant un lot de règles préprogrammées (environ 400 actuellement).

Ces règles permettent de détecter les problèmes de :

• Sécurité du code
• Performance
• Fiabilité
• …

Elle permettent aussi de s’assurer de la qualité du code source (JavaDoc, Code mort…) et du respect des règles de nommages (fonctions et variables) en application dans la société concernée et des standards de programmation du monde Java.

JTest permet aussi d’automatiser la génération intelligente de cas de tests JUnit, ce qui permet de faciliter les tests unitaires.

Principaux concurrents :

Pure Coverage, Purify et Quantify d’IBM Rational servent respectivement à repérer les codes non utilisés (codes morts), à détecter les fuites mémoires et à analyser les performances. Pour le monde Open Source PMD et CheckStyle sont les principaux concurrents à JTest.

2.  Fonctionnement de JTest

JTest est présenté sous la forme d’un programme Java, une fois lancé et paramètré sur un code source ou un gestionnaire de sources de type CVS il génère un rapport sous forme XML et au format HTMLHTML (HyperText Markup Language) est un langage permettant de décrire le découpage d'une page web.. Il est possible d’activer l’option de rapport par développeur, JTest peut alors se baser sur le tag @author de la JavaDoc du code source au bien sur l’utilisateur CVS qui a soumis en dernier la source au référentiel.

2.1.       Rapport JTest au format HTML

Aperçu d’un rapport JTest au format HTML : 

On peut remarquer sur ce rapport que les annotations sont regroupées par catégorie (Convention de codage, formatage…) puis par règle avec l’indicateur qfix (Quick Fix) positionné sur les règles dont l’implémentation de la solution est rapide.

2.2.       Rapport JTest au format XML

Extrait d’un rapport JTest au format XML : 

La balise contient la liste des développeurs paramètres pour cette session de test.

On peut constater sur cet extrait que chaque balise correspond à un problème constaté avec l’auteur concerné (auth), la catégorie de règle (cat), la clé de hachage de l’instruction (hash), le langage informatique de l’instruction (lang), la ligne concernée (ln), le fichier source concerné (locFile), le nombre de caractères concernés dans l’instruction (locLen), le premier caractère de la ligne concerné (locOffs), le message de l’erreur (msg),  le niveau de sévérité associé (sev) et le code de la règle correspondante (rule). Le niveau de sévérité d’une annotation va de 1 à 5 où 5 est le niveau de sévérité le plus grand.

Ce fichier XML contient aussi la liste des règles activées pour cette session de test. Chaque règle est introduite par la balise avec sa catégorie (cat), sa description (desc), son identifiant (id), son marqueur indiquant si la correction est rapide à mettre en place (qfix) et son niveau de sévérité (sev).

Les catégories de règles sont aussi présentent dans ce rapport XML par l’intermédiaire de chaque balise avec comme attribut la description de la catégorie (desc) et le nom de celle-ci (name).

La liste des catégories étant pour la version 8 de JTest :

• Convention de codage
• Gestion des exceptions
• Formatage
• Gestion du ramasse miette (Garbage Collector)
• Gestion des constantes
• Commentaires JavaDoc
• Connectivité Java aux bases de données
• Métrique de classe
• Divers
• Conventions de nommage
• Optimisation
• Bogue possible
• Portabilité
• Code mort

De plus il est possible d’ajouter des règles supplémentaires à JTest en fournissant leur implémentation. Dans notre exemple les erreurs correspondantes à ces règles supplémentaires sont affichées dans des balises de type .

Ce lot d’informations permet de localiser précisément l’instruction concernée dans le code source et d’y afficher le message correspondant.

Les catégories couplées au niveau de sévérité permettent de filtrer ces annotations. L’AGL open source Eclipse, largement utilisé pour le développement d’applications Java dispose en interne de trois types d’annotation :

• Les erreurs (errors)

• Les avertissements (warning)

• Les informations (infos) 

2.3.       Utilisation du plugin JTest pour Eclipse

Avec le rapport JTest au format XML Il est donc possible de convertir les annotations JTest en annotations Eclipse. Pour permettre cette conversion Parasoft propose un plugin Eclipse permettant d’y intégrer un rapport JTest. [

][7]

Aperçu des annotations JTest visible sous l’AGL Eclipse : 

En double cliquant sur une erreur un développeur sera redirigé vers celle-ci directement dans le code source de l’application.

L’utilisateur sait alors précisément quelle instruction doit être corrigée, de plus il peut dans la fenêtre ‘Package Explorer’ visualiser sur quelles classes il y a des annotations critiques.

En passant sur l’annotation JTest le développeur peut apercevoir le libelle de celle-ci.

2.4.       Documentation sur les erreurs JTest

Pour faciliter la tâche des développeurs Parasoft fournit une documentation au format PDF et HTML détaillant pour chaque annotation :

• Sa description
• Une note
• Le problème de sécurité
• Les paramètres
• Les bénéfices de la correction
• Les inconvénients du problème
• Depuis quelle version de JTest cette annotation est valide
• Un exemple du problème
• Ce même exemple corrigé
• Des liens vers des références externes

Aperçu de la documentation d’une annotation JTest au format HTML : 

3.  Utilisation de JTest dans le cadre d’un projet

3.1.       Les différentes utilisation de JTest possibles

JTest peut être utilisé de deux manières différentes dans le cadre d’un projet informatique.

La première solution consiste à installer sur tous les postes de développement le plugin JTest pour Eclipse commercialisé par Parasoft. Le développeur aura alors le choix de lancer lui-même lorsqu’il le désire l’analyse de tout le code ou de simplement une classe Java ou un package. Cette possibilité permet une grande liberté pour les développeurs cependant la consommation en ressource système de l’analyse JTest les dissuadera rapidement de lancer trop souvent une telle analyse. Ce mode de fonctionnement permet aussi aux développeurs de laisser JTest corriger lui-même les erreurs. Cette automatisation de la correction est très pratique lorsqu’une erreur simple est présente à de nombreux endroit dans le code, cependant lorsque la correction est plus complexe il est difficile d’être certain de la conformité du résultat obtenu. Enfin cette solution oblige l’entreprise en question à acquérir une licence cliente de JTest pour chaque poste de développement, à 4 000 € environ la licence cliente JTest la facture devient rapidement très salée.