Blog du testeur

Lint est un outil d'analyse statique qui permet de détecter des anomalies avant même d'entamer les tests unitaires. Pour pas cher il vous permettra de détecter des bugs potentiels.

Si vous télécharger le bundle de développement android il se trouve sous le répertoire Tools du sdk.

Il se lance en ligne de commande:



Le résultat est affiché directement dans la console mais il est possible de générer un rapport en utilisant l'option:

./lint --html report.html /Users/dominiquemereaux/Android/SpinnerTest
Regardons de plus près ce rapport:



Il m'informe que je n'ai pas précisé le SDK min et max que mon application est sensée supporter.
Il me donne également des conseils pour corriger:



Les problèmes détectés sont classés dans les catégories suivantes:

• correctness
• security
• performance
• usability
• accessibility
• internationalization

Vous trouverez la liste des problèmes détectés à cette adresse:
lien

Jlint est un outil d'analyse statique basé en particulier sur le "dataflow analysis" qui permet de détecter des erreurs avant même d'avoir exécuter le code. Ce type d'outil permet d'améliorer à moindre coût la maturité et la maintenabilité du code.

Exemples d'erreur détectée

"return always true": effectivement la variable locale deltaV est initialisée à 0 au début et comparée à 0!

shadows component of class 'echec/PieceEchiquier': la variable locale a le même nom que l'un des éléments de la classe:

La page d’accueil de l'outil:

Jlint

Les sources sont téléchargés sous forme de zip. Un makefile permet de générer l'exécutable sous n'importe quelle plateforme.

Il contient un autre outil complémentaire détectant des erreurs de code telle que le signe '=' utilisé au lieu de "==". Dans ce cas il faudra utiliser l'option -java pour un programme java.

Dans le zip vous trouverez également un pdf décrivant les types d'erreurs détectées.

Diminution des coûts :

L’utilisation des outils d’analyse de code permet de faire de la prévention, c’est à dire trouver des défauts avant d’exécuter le code lors de tests unitaires, intégration ou système.

Exemple:

1. Lancement de l’outil sur un code java :



2. Résultat de l’analyse :


3. Détail du défaut :

Le test est effectivement toujours à vrai. Manque-t-il un appel une méthode pour calculer deltaV? Cette condition est-elle finalement inutile ?

Détecter un défaut à ce niveau permet une correction immédiate et limite de fait les coûts de test :

Le volume d’anomalies impacte le nombre de phases de tests nécessaire à l’obtention d’un niveau de qualité, et donc le coût (et les délais).
Le nombre de phases minimum est de trois, mais peu être plus élevé si la volumétrie d'anomalie est importante.
On pourrait mesurer l'efficacité de ces outils en calculant le nombre de défauts détectés répartis par gravité.

Maintenabilité, maturité :

1. Autre exemple : utilisation d’un résultat boolean d’une méthode de façon « inversée »



2. Visualisation du code :



3. Recherche de l’utilisation de la méthode :



4. Effectivement la négation est utilisée :



5. L’outil d’analyse propose même une correction automatique :

Ici je peux remplacer estValide par estNonValide, l’outil fera automatiquement les corrections y compris dans la fonction appelante.

En simplifiant le code (suppression des négations) je rend le code plus maintenable est évite les erreurs de codage liées à l’utilisation des négations.

Par une lisibilité plus importante, le coût de la maintenance pourra être diminuée.
Remarque, en offrant ces fonctions de corrections automatiques, la production de code devient plus efficace.

Les exemples ont été réalisés avec Intelliji IDEA.