Sondez votre code avec SonarQube

Quoi sert SonarQube ?

SonarQube est un outil d’analyse statique qui a pour but de mesurer la qualité du code d’un applicatif. Pour un projet donné, il fournit des métriques portant sur la qualité du code et permet d’identifier précisément les points à corriger (code mort, bugs potentiels, non-respect des standards, carence ou trop-plein de commentaires…)

L’analyse SonarQube ne remplace en aucun cas les tests unitaires, mais permet d’identifier rapidement certains défauts du codes.

Lancer une analyse SonarQube sur un projet

Prérequis

Installer SonarQube (voir la documentation officielle).

Démarrer votre instance avec la commande :

service sonar start

Configurer l’analyse SonarQube

  • A la racine du projet, créer un fichier intitulé « sonar-project.properties ».
  • Compléter ce fichier avec le texte suivant :

sonar.projectKey=nom.du.projet

sonar.projectName=Nom du projet

# La version de votre projet, pas celle de SonarQube
sonar.projectVersion=1.0

# Définit l’emplacement des sources que SonarQube va analyser.
sonar.sources=.

# A décommenter si besoin
#sonar.sourceEncoding=UTF-8

  • Toujours à la racine du projet, lancer la commande « sonar-scanner ».

Fonctionnalités de SonarQube

Faisons le tour des principales features de SonarQube.

Analyse des résultats SonarQube

En supposant que SonarQube soit installé en local, les résultats de l’analyse seront consultables sur http://localhost:9000/sonar/. Chaque projet dispose d’un espace d’analyse dédié.

SonarQube classe les défauts logiciels selon 3 catégories :

  • Les bugs : anomalies évidentes du code. Impactent la fiabilité (reliability) de l’application.
  • Les vulnérabilités : faiblesses du code pouvant nuire au système. Impactent la sécurité de l’application.
  • Les « code smells » : anti-patrons (ou anti-patterns). Impactent la maintenabilité de l’application.

Qu’est-ce qu’un code smell ?

En peu de mots, du code qui sent le roussi ! Wikipedia donne quelques exemples de code smells. En général, SonarQube détecte davantage de code smells que de bugs ou de vulnérabilités.

Ecran d’accueil de SonarQube

Sur l’écran d’accueil d’un projet analysé par SonarQube se trouve un récapitulatif des grandes familles de défauts :

La mention « Passed » signifie que le projet satisfait les exigences minimum définies dans l’espace « Barrières qualité ». Les paramètres par défaut peuvent être adaptés.

Onglet « Défauts »

Dans cet onglet, chaque bug, vulnérabilité ou code smell est répertorié et détaillé dans une liste.

L’intérêt immédiat, orienté projet : tel un outil de bugtracking ou de gestion de tickets, cette liste permet de prioriser les points à traiter, d’évaluer leur temps de correction et de les affecter à un développeur. Le statut de chaque défaut est affiché. Les options du projets, tels que l’utilisateur affecté par défaut, peuvent être configurés (onglet « Configuration » -> « Configuration du projet »).

En se positionnant en vue « Effort », on peut également voir le temps total que prendrait la correction de tous les défauts du code, ce qui peut faciliter la planification du travail d’un développeur lors d’un sprint par exemple.

Le second intérêt, orienté humain : comme chaque défaut comporte une explication détaillée et des pistes d’amélioration, le développeur est susceptible de monter en compétence et d’améliorer à long terme la qualité de son code.

Onglet « Mesures »

On y trouve des infos supplémentaires, plus générales, telles que la complexité du projet et le pourcentage de commentaires (20% étant habituellement reconnu comme un bon pourcentage). Contrairement à l’écran précédent, celui-ci n’est pas très bavard : à l’utilisateur de trancher si le taux de complexité est acceptable, par exemple. Pour en savoir plus sur les méthodes de calcul de la complexité, rendez-vous ici.

Onglet « Code »

Cet onglet est particulièrement pratique. Il permet de visualiser, fichier par fichier, les problèmes identifiés par SonarQube. Le code est intégralement affiché, avec des icônes au niveau des lignes posant problème.

Onglet « Tableau de bord »

Sur cette page sont rassemblées un grand nombre de métriques utiles pour communiquer sur la qualité du code. Les dashboards sont configurables selon un grand nombre de paramètres.

Penchons-nous maintenant sur le cœur de SonarQube, à savoir la définition des règles de qualité du code.

Gestion des règles SonarQube

Liste des règles

La liste exhaustive des règles associées aux défauts est disponible à cette adresse : http://localhost:9000/sonar/coding_rules.

Dans cet espace, il est possible de modifier la sévérité associée à chaque défaut. La détection de certains défauts peut aussi être désactivée.

Adapter les règles SonarQube existantes

Le contenu de certaines règles peut être configuré. Par exemple, la règle de nommage des variables locales en Java est vérifiée grâce à une expression régulière qui peut être changée :

Créer des règles SonarQube à partir d’un modèle (template)

Dans la liste des règles, cochez la case « Montrer uniquement les modèles ». A partir des modèles disponibles, vous pourrez créer de nouvelles règles.

Cette fonctionnalité est appréciable, mais il est dommage qu’il y ait si peu de modèles disponibles.

Création de nouvelles règles SonarQube

Il est possible de créer de nouvelles règles ex nihilo, mais la démarche est un peu plus lourde. Effectivement, il est nécessaire pour cela de créer un plugin SonarQube, et donc de maîtriser l’architecture des sources. Mode opératoire ici

Lancer une analyse SonarQube depuis Jenkins

Pour intégrer pleinement SonarQube à votre démarche d’intégration continue, nous vous suggérons de déclencher des lancements automatiques de l’analyse du code depuis Jenkins.

Pour ce faire :

  1. Installez le plugin SonarQube
  2. Générez un token dans l’interface SonarQube. Pour ce faire, une fois connecté, cliquez sur votre profil, puis sur « My account » et « Generate tokens ».
  3. Cliquez sur « Administrer Jenkins » puis sur « Configurer le système ». Dans la partie « SonarQube servers », entrez le token précédemment généré.
  4. Créez un job et configurez-le. Créez une étape de build « Lancer une analyse avec SonarQube Scanner ». Si vous ne remplissez pas les champs, ce sont les informations présentes dans le fichier sonar-project.properties qui seront prises en compte.

SonarQube et Jenkins Pipeline

Comme nous sommes de plus en plus nombreux à mettre en place ce type de jobs, voici un exemple de pipeline très simple réalisant une analyse SonarQube :

node {
    
    // Lors de cette phase de setup, nous récupérons dans le workspace de Jenkins les sources à analyser.
   stage(‘Setup’) {
       checkout([$class: ‘GitSCM’, branches: [[name: ‘*/master’]], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: ‘***clé générée par le plugin Credentials de Jenkins***’, url: ‘http://votresuperdepot.git’]]])
   }
   
    stage(‘Analyse SonarQube’) {
        // Le nom du « tool » et de l’argument de « withSonarQubeEnv » correspond au nom de l’instance SonarQube telle que défini dans Jenkins, dans « Configurer le système » > « SonarQube servers » > « Installations de SonarQube » > « Nom »       
        def scannerHome = tool ‘Sonar’;
        withSonarQubeEnv(‘Sonar’) {
            sh « ${scannerHome}/bin/sonar-scanner »
        }
   }

}

Ce qu’il ne faut pas attendre de SonarQube

Une exactitude indiscutable

Chaque défaut identifié par SonarQube doit être qualifié ; nul logiciel de test automatisé n’est à l’abri d’un faux positif.

Un substitut aux revues de code

Les analyses quantitatives fournies par SonarQube peuvent être trompeuses : ce n’est pas parce que 20% des lignes d’une application sont des commentaires que ceux-ci apportent de la valeur ajoutée. De même, ce n’est pas parce que SonarQube n’a pas identifié de duplicats que le programme ne comporte pas de redondances.

Même si SonarQube est très utile pour identifier des défauts spécifiques et donner une vision d’ensemble de la qualité du code, ses analyses gagnent à être complétées par une revue de code réalisée par un humain.

Conclusion

SonarQube permet d’identifier très rapidement les anomalies de code d’une application. Mais c’est une solution qui doit aller de pair avec une stratégie globale de qualité de code. Il faut connaître son applicatif afin de pouvoir analyser les reportings, trancher sur ce qu’il faut ou non corriger et fixer des seuils en-deçà desquels la qualité sera jugée insuffisante.

Vous aimerez peut-être…

La qualité de code en direct avec SonarLint !

SonarQube met son grain de sel dans Gitlab !

Katalon en 12 questions – réponses

Note du 6 janvier 2020 : Veuillez noter que cet article a été publié en mai 2017 et qu’il se base donc sur une version ancienne de Katalon. Cet outil a connu un essor impressionnant et propose des fonctionnalités qui n’existaient pas auparavant. Avant de prendre une décision quant à la mise en place de cet outil dans votre organisation, il sera pertinent de se pencher aussi sur des témoignages plus récents. Bonne lecture !

1) Qu’est-ce que Katalon ?

Katalon Studio est un framework basé sur Selenium et Appium, qui permet d’automatiser les tests web et mobiles. Dans cet article, nous découvrirons ensemble comment créer un cas de test mobile sur un téléphone Android.

Nous apporterons des réponses aux questions que nous-mêmes nous nous sommes posées avant de commencer avec Katalon. Notre SUT (system under test) sera l’application Observatoire des prix, qui permet de comparer produit par produit les tarifs pratiqués par les grandes surfaces en Nouvelle Calédonie. Développée par One Shot, cette application est une commande du Gouvernement de la Nouvelle Calédonie dans le cadre de la lutte contre la vie chère.

2) Quels systèmes d’exploitation Katalon supporte-t-il ?

Même si cela paraît étonnant, à ce jour, Katalon peut être installé sur Windows, Mac… mais pas sur Linux (source).

EDIT du 3 avril 2019 : Linux est maintenant pris en charge (en bêta), merci à un de nos lecteurs de nous l’avoir signalé par commentaire !

3) Katalon est-il gratuit ?

Développé d’abord en interne par KMS Technology, le projet a ensuite été partagé avec la communauté. L’outil est donc (et a priori restera) disponible gratuitement.

4) Comment débuter avec Katalon ?

Katalon nécessite quelques pré-requis, mais le démarrage se fait facilement. C’est une des exigences du produit, qui se veut accessible à tous.

Voici votre checklist de démarrage :

  • NodeJs est installé
  • Appium est installé (cela peut se faire indifféremment avant ou après l’installation de Katalon). Il faudra ensuite, dans l’interface Katalon, déclarer l’emplacement d’Appium.
  • Votre téléphone Android est branché à votre ordinateur via un câble USB.
    • Attention, votre téléphone ne doit pas être verrouillé par un mot de passe ou autre code durant l’exécution des tests. En l’état, Katalon ne permet pas de gérer le déverrouillage.
    • Autre point à vérifier : l’écran ne doit pas s’éteindre trop vite. Configurez votre téléphone pour que son écran s’éteigne au bout du seuil maximum.
    • EDIT du 8 février 2019 : ces points semble avoir avancé, voir la documentation dédiée au déverrouillage d’écran.
  • Le mode développeur est activé sur votre téléphone. Pour ce faire, il faut cliquer 7 fois sur le numéro de version (on dirait une formule magique ce n’est pas une blague !). L’emplacement de cette information dépend du téléphone, mais on peut trouver par exemple dans Paramètres > A propos de l’appareil > Infos logiciel.
  • Le débogage USB est autorisé sur votre téléphone. Rendez-vous dans les « Option de développement » qui apparaissent dans le menu principal lorsque le mode développeur est activé. Une popup apparaît pour demander si l’on peut faire confiance à l’ordinateur connecté. Si cette popup n’apparaît pas, débrancher et rebrancher le téléphone.

5) La documentation de Katalon est-elle suffisante ?

Les quelques modes opératoires qui existent sont clairs, mais ils sont peu nombreux. Le forum Katalon comble en partie ce manque. Extrêmement réactif, il nous a à chaque fois permis d’obtenir des réponses à nos questions en quelques heures seulement !

En-dehors du site officiel, il existe peu de ressources sur cet outil. A ce jour, aucune question n’a été posée sur Katalon sur le célèbre forum StackOverflow. EDIT du 27/03/2019 : ce n’est plus le cas ! Voici différentes étapes du développement du sujet sur ce site de questions-réponses.

Avril 2017 : le désert

En avril 2017, il n'y avait aucun post StackOverflow sur Katalon

Janvier 2018 : l’éclosion

En janvier 2018, il y avait 80 posts StackOverflow sur Katalon

Mars 2019 : l’explosion

En mars 2019, nous constatons qu'il y aura bientôt 600 posts StackOverflow sur Katalon

Juin 2020

(Au passage, on admire le nouveau mode nuit de StackOverflow… synonyme de confort supplémentaire et de meilleures performances environnementales !)

En juin 2020, on approche les 1000 posts

6) Les cas de test Katalon sont-ils maintenables ?

Quel sentiment magique ressent le testeur lorsque, pour la première fois depuis le début du projet, il lance son arsenal de tests automatisés…

Hélas, cette touchante émotion peut vite laisser place au désappointement si la maintenabilité n’a pas été au coeur de la conception de l’architecture des tests.

Heureusement, Katalon répond à cette problématique essentiellement grâce à 2 fonctionnalités :

  • le dépôt d’objets (object repository)
  • les mot-clés personnalisés (custom keywords)

Reconnaissance des objets avec l’Object repository

Comme avec UFT, que nous présentions précédemment, l’object repository permet de gérer en un même lieu tous les identificateurs d’éléments de l’interface. Un atout indispensable en cas de refonte de l’ergonomie. Au lieu de modifier chacun des tests utilisant un même objet, on ne modifie que la définition de l’objet ayant subi une modification.

Pour alimenter l’object repository, il faut utiliser l’un des deux outils de capture : « Spy Web » et « Spy Mobile ». L’utilisateur sélectionne alors, en s’aidant d’une preview, les objets qui l’intéressent. Pour ceux à qui cela fait peur, pas besoin de mettre le nez dans le code.

Le testeur peut ensuite cocher ou décocher les cases qu’il trouve les plus pertinentes.

Encapsulation d’actions avec les Custom keywords

Les custom keywords sont en fait des méthodes (au sens programmatique du terme) que l’on peut appeler au sein des cas de test. Prenons par exemple l’enchaînement d’actions permettant l’authentification d’un utilisateur : au lieu de copier-coller, au sein de chaque cas de test, qu’il faut :

  1. Vérifier que l’on se trouve sur la page d’authentification
  2. Entrer tel identifiant
  3. Entrer tel mot de passe
  4. Cliquer sur le bouton « Valider »
  5. Attendre que la page d’accueil apparaisse

Il suffit de créer un custom keyword qui prenne en paramètre l’identifiant et le mot de passe.

Cela améliore à la fois la lisibilité du test, car il y a moins d’étapes, mais aussi sa maintenabilité. Par exemple, si un jour une case « Se souvenir de moi » est ajoutée à cette page de connexion, il suffira d’ajouter une étape au custom keyword, et un paramètre pour choisir si l’on souhaite cocher la case ou non.

Notre conseil : bien réfléchir à l’organisation de ces custom keywords avant de se lancer à corps perdu dans l’automatisation des scripts de test. Sans cette étape, la scalabilité de votre projet risque d’en prendre un coup.

7) Katalon s’intègre-t-il avec Jenkins ?

Oui, on peut faire de l’intégration continue avec Katalon et Jenkins. Mais souvenez-vous… pas sur une machine Linux.

Dans l’interface de Katalon, cliquez sur le bouton « Build CMD », configurez votre exécution, puis copiez la commande générée.

Sur une instance Jenkins installée une machine Windows, créez un job free-style et ajoutez une étape de build « Exécuter une ligne de commande batch Windows ».

La commande à exécuter est la suivante :

cd chemin/vers/katalon.exe
[commande générée précédemment via Katalon]

Ce qui donne quelque chose comme ça :

Une limitation à noter

Les rapports de test sont stockés dans le dossier « Reports » consultable dans Katalon, et non pas dans le workspace de Jenkins. Nativement, un tel job ne permet pas d’en déclencher un autre (un fonctionnement courant dans une démarche d’intégration continue).

8) Puis-je lancer des tests automatisés sur iOS ?

Oui, mais seulement depuis un Mac (source).

9) Katalon s’interface-t-il avec des bugtrackers ou des outils de test management ?

A l’heure actuelle, Katalon s’interface avec Jira pour la gestion des anomalies et qTest pour la gestion des cas de test.

10) L’interface de Katalon est-elle user-friendly ?

C’est assez subjectif mais nous avons trouvé que oui. L’interface rappelle beaucoup celle d’Intellij.

L’outil a été conçu pour être utilisé aussi bien par des automaticiens que par des testeurs ne sachant pas programmer. Les cas de test peuvent donc être conçus en mode « manuel » ou en mode « script » (à noter que les scripts sont en Groovy).

A notre sens, utiliser cet outil peut être un bon moyen de s’initier en douceur aux joies du code. Mais il ne faut pas oublier que certaines fonctionnalités ne peuvent être exploitées pleinement qu’en mode script, par exemple les custom keywords.

A titre d’exemple, voici à quoi ressemble un cas de test en vue manuelle :

Et le même test en vue script :

Côté automatisation web, Katalon propose une fonctionnalité de capture-rejeu (ou playback) qui pourra vous rappeler Selenium IDE. Attention, il ne faut pas en abuser, car en tant que tels ces enregistrement sont un cauchemar pour la maintenance !

11) Existe-t-il une version de Katalon en français ?

Certaines organisations mettent un point d’honneur à utiliser des outils pouvant être configurés en français. Mais en l’occurrence, la réponse est non. De manière générale, il ne fait pas bon être francophone quand on se sert de Katalon… Vous utilisez des caractères spéciaux dans le mode Script ? Vous avez tort. Vraiment.

En mode manuel, heureusement, les caractères spéciaux s’affichent correctement.

Dans le même esprit, dans la popup d’identification des objets web, le raccourci d’enregistrement est Alt + ~. Infaisable avec un clavier français, sachant que la tilde nécessite trois touches différentes… Et à l’heure actuelle, ce raccourci n’est pas configurable dans les options de Katalon. EDIT du 17 avril 2019 : des solutions semblent avoir été apportées entre temps.

Ce ne sont que des détails, mais il est bon de le savoir avant de se lancer.

12) De manière générale, l’automatisation mobile est-elle plus difficile que l’automatisation web ?

Avec Katalon, non, pas vraiment. La gestion des appareils mobiles ajoute un peu de temps de configuration, mais cela ne fait pas de grande différence.

Le problème de l’identification des objets

Mais de manière générale, une application mobile peut être plus difficile à tester si l’équipe de développement n’a pas envisagé la possibilité que des tierces personnes relisent leur code… Lors de la capture des objets, on peut en effet se retrouver face à une liste interminable d’objets aux noms peu parlants.

Super clair !…

Pourquoi est-ce un problème ?

  • Parce que l’automaticien n’est pas toujours sûr de sélectionner le bon objet. Si deux écrans sont superposés et que chacun possède un bouton positionné au même endroit, même le mode visuel ne permet pas de savoir si l’objet sélectionné dans la liste est le bon.
  • Et surtout, parce que la spécificité des identificateurs impacte la robustesse des scripts d’automatisation. Un identificateur comprenant, en dur, un nombre arbitraire (tel bouton est le 27è de la page) est moins robuste qu’un identificateur défini par un « id » unique (« btn_enregistrer » par exemple).

Ce problème peut aussi exister au sein des applications web, mais dans une moindre mesure. En effet, les « id » et les « class » utilisées entre autres pour appliquer une mise en forme CSS au document sont d’une grande aide pour l’automaticien (sauf cas particuliers d’id générés automatiquement).

Ce problème n’est pas propre à Katalon. Si possible, incitez au plus tôt dans le projet les équipes de développement à créer des identificateurs d’objets « automation-friendly ».

Conclusion

Sans conteste, Katalon est un excellent outil. Il est même étonnant qu’il soit si peu connu.

Nous pensons que son plus gros défaut est malheureusement son incompatibilité avec Linux. On peut également déplorer une intégration trop superficielle avec Jenkins. L’outil a bien évolué depuis la publication initiale de cet article ! Voir cette documentation pour l’intégration à Jenkins, via un plugin dédié.

Si ces contraintes ne vous concernent pas, nous vous le recommandons chaleureusement. Nous serons heureux d’avoir vos retours sur ce logiciel.

Et pour en savoir plus sur l’automatisation des tests, nous vous conseillons cette ressource !