TestMethodOrder : un coup de pouce à utiliser avec précaution

JUnit et son ordre fantasque

Dans certains contextes techniques, nous pouvons choisir simplement l’ordre d’exécution des tests automatisés. Par exemple, Test Batch Runner permet de lancer une suite de tests UFT selon l’ordre indiqué dans le fichier mtb (modular test batch) associé.

En revanche, quand on utilise JUnit, par défaut, ce n’est pas le cas. Le nom des méthodes de test sont hashées, puis les tests sont lancés par ordre alphabétique de hash. Nous nous retrouvons donc à chaque fois avec le même ordre d’exécution, mais à première vue celui-ci ne rime à rien. Ça peut même être assez agaçant au début quand on découvre l’outil !

Un test d’indépendance

Si vos tests autos respectent une des bonnes pratiques capitales en la matière, à savoir qu’ils sont tous indépendants les uns des autres, cela ne devrait cependant pas vous poser problème. En principe, ils devraient pouvoir être joués dans n’importe quel ordre.

Le fait que JUnit lance les tests dans cet ordre particulier peut donc être apprécié, et utilisé comme une manière de vérifier que les tests sont bien indépendants les uns des autres. Du coup, pourquoi ne pas aller encore plus loin ?

Soyons encore plus fous

Pour aller au bout de la logique, nous pourrions décider de jouer les tests dans n’importe quel ordre, cet ordre pouvant changer à chaque exécution. Pour cela, nous allons nous baser non plus sur le hash des noms de méthodes, mais sur l’ordre d’exécution de la JVM, qui n’est pas fixe. Pour ce faire, ajouter simplement « @FixMethodOrder(MethodSorters.JVM) » juste au-dessus de votre classe de test. Cette solution est compatible avec JUnit 4.

@FixMethodOrder(MethodSorters.JVM)
public class TestExemple {

    @Test
    public void test001(){
        System.out.println("1");
    }

    @Test
    public void test002(){
        System.out.println("2");
    }

    @Test
    public void test003(){
        System.out.println("3");
    }

}

Vos tests se joueront maintenant dans n’importe quel ordre, ce qui vous permettra de prouver qu’ils sont vraiment indépendants.

Un ordre fixe

Maintenant, il peut arriver que vous ayez besoin de lancer les tests dans un certain ordre. Si tel est le cas, il suffit simplement de remplacer « MethodSorters.JVM » par « MethodSorters. NAME_ASCENDING », et de ranger les tests par ordre alphabétique en fonction de l’ordre voulu. Cette solution est compatible avec JUnit 4.

D’autres méthodes sont arrivées avec JUnit 5. Par exemple, ceci affichera 1, 2, puis 3, en se basant sur les annotations @Order :

@TestMethodOrder(MethodOrderer.OrderAnnotation.class)

public class TestExemple {

    @Test
    @Order(2)
    public void ccc(){
        System.out.println("2");
    }

    @Test
    @Order(1)
    public void bbb(){
        System.out.println("1");
    }

    @Test
    @Order(3)
    public void aaa(){
        System.out.println("3");
    }
}

Pour conserver un ordre alphabétique et ne pas s’encombrer d’annotations, la syntaxe suivante peut être suivie :

@TestMethodOrder(MethodOrderer.Alphanumeric.class)

public class TestTmp {

    @Test
    public void bbb(){
        System.out.println("2");
    }

    @Test
    public void ccc(){
        System.out.println("3");
    }

    @Test
    public void aaa(){
        System.out.println("1");
    }

}

Celle-ci affichera 1, 2, puis 3.

Quelle que soit la notation choisie, si vous optez pour cette logique, pesez bien le pour et le contre avant de vous lancer.

Exemple de mauvaise utilisation

Une rangée de dominos peut tenir debout pendant des années. Mais il suffit que l’inscription de Boniface07 se déroule avec un petit accroc pour que tous les tests de cette classe se retrouvent en échec.

FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class TestExemple extends MaSuperAppliWebTest {

    @Test
    public void test001_inscriptionUtilisateur(){
        accesURL("https://masuperappliweb.com/inscription");
        inscription("Boniface07", "password");
        verifierMessageConfirmationInscription();
    }

    @Test
    public void test002_premiereConnexionUtilisateur(){
        accesURL("https://masuperappliweb.com/connexion");
        connexion("Boniface07", "password");
        verifierPageAccueilAffichee();
    }

    @Test
    public void test003_configurationCompte(){
        accesURL("https://masuperappliweb.com/connexion");
        connexion("Boniface07", "password");
        configurerCompte();
        verifierCompteBienConfigure();
    }

}

Un exemple de motif recevable

Le test X a besoin d’un jeu de données. Celui-ci peut être rapidement créé via une IHM, mais un traitement en back-office durant environ 15 minutes doit être effectué. Nous n’avons pas envie de gaspiller 15 précieuses minutes à attendre la fin de ce traitement ! Nous lançons donc cette création de données au début, nous jouons une flopée de tests ensuite, et seulement à la fin, le test devant utiliser le jeu de données. Des commentaires clairs font état de cette dépendance exceptionnelle. On pourrait même dire qu’on est en présence d’un seul scénario coupé en deux méthodes de test.

Ce n’est pas le seul motif recevable, mais cet exemple montre que cela doit rester exceptionnel et justifié.

A bientôt et bonne automatisation des tests !

Les Relative Locators de Selenium 4 : cas d’usage

16 ans déjà que Selenium existe ! Première version en 2004, Selenium 2 en 2011, Selenium 3 en 2016, et depuis le printemps 2019 il est déjà possible de s’amuser avec Selenium 4. Toujours en version alpha en février 2020, cette nouvelle mouture propose entre autres une nouvelle manière d’identifier les éléments d’une page web : les Relative Locators. Vous qui avez à coeur de faire de la veille sur les outils de test automatisé, c’est le moment de découvrir cette nouvelle fonctionnalité !

Que sont les Relative Locators ?

Vous connaissiez déjà les multiples manières proposées par Selenium pour identifier les objets : par attribut « id » ou « name », par « tag » (balise HTML), par xPath et par sélecteur CSS.

En plus de ces différentes manières, il est désormais possible de sélectionner des élément en fonction de leur position par rapport à d’autres éléments. Par exemple : l’image qui se trouve en-dessous du menu, le lien qui se trouve à gauche du logo, le bouton qui se trouve près (moins de 50 pixels) du footer. Seul l’élément par rapport auquel on se positionne nécessite un sélecteur ; pour l’élément cible, on n’indique que le nom de sa balise HTML.

Exemple de Relative Locator

// Avant
WebElement imageEnDessousDuMenu = driver.findElement(By.xpath("//div[@id=’menu’]//..//img")); // Ca ne vérifie pas que l’image est en-dessous du menu, juste qu’ils ont le même parent, par exemple une div

// Après
WebElement imageEnDessousDuMenu = driver.findElement(withTagName("img").below(By.id("menu")));

Les Relative Locators devaient d’abord s’appeler « Friendly Locators », et on comprend pourquoi : en intégrant dans le framework des notions visuelles, le code peut devenir plus simple à lire.

Sans vouloir jouer les trouble-fêtes…

Pour autant, nous n’avons pas réussi à nous souvenir de cas où ces localisateurs nous auraient vraiment sauvé la vie. Jusqu’à présent, nous avons toujours pu trouver des solutions satisfaisantes et robustes se basant sur les localisateurs historiques. Alors, les Relative Locators seraient-ils un ajout « sympa mais pas si utile » ?

Peut-on maintenant vérifier la position des éléments ?

Alors… si, il y a bien quelque chose qui pourrait être très utile : ce serait de vérifier la position relative d’un élément par rapport à un autre.

Comment ça, ce n’est pas ce qu’on vient de faire ?

Hé non, pas tout à fait. Certes, à chaque fois que notre code Selenium interagit avec un élément, cela nous permet de savoir qu’il existe. Pour autant, si le localisateur de notre « imageEnDessousDuMenu » renvoie une erreur « NoSuchElementException », on ne saura pas si c’est parce qu’il n’y a pas d’image sur la page, si le menu a changé d’ID, ou s’il y a bien la bonne image mais qu’elle n’est plus en-dessous mais au-dessus. Et parfois, on a besoin de savoir précisément si tel élément est bien situé par exemple à un autre. Par exemple, quand on teste le caractère responsive d’une page web.

Nous pensions que Selenium 4 arriverait avec des méthodes pratiques facilitant les assertions, du genre isElementBelow(WebElement unAutreElement), mais ce n’est pas (encore ?) le cas.

Cependant, il est bien sûr possible de s’en sortir avec des méthodes sur mesure.

Ce qui nous amène à notre exemple de mise en application !

Test de position des éléments avec Selenium 4

Cas d’usage : plein écran et demi-écran

Je visite le site https://service-public.nc/ depuis mon ordinateur portable, dont le système d’exploitation est Windows 10. La fenêtre de mon navigateur est au maximum. Ce que je lis est intéressant, je voudrais prendre des notes : je fais basculer mon navigateur en mode demi-écran, pour avoir le bloc-notes sur l’autre partie de l’écran.

Sur la page d’accueil du menu « Particuliers », en plein écran, les blocs se présentent ainsi :

En responsive, les blocs se réorganisent. Je souhaite évidemment que les éléments du site soient visibles et cohérents dans les deux affichages.

Vues différenciées

Vue desktop

Vue « demi-desktop »

Assertions à faire

Dans notre test automatisé Selenium 4, nous allons vérifier les assertions suivantes.

En mode desktop :

  • Le titre « Particuliers » est au-dessus de l’article 1
  • Le titre « Particuliers » est à la même abscisse (X) que l’article 1
  • Le titre « Particuliers » est à la même ordonnée (Y) que le bloc « Vos services en un clic »
  • Le titre « Particuliers » est à gauche du bloc « Vos services en un clic »
  • L’article 1 est à la même ordonnée (Y) que l’article 2
  • L’article 1 est à gauche de l’article 2.

En mode « demi-desktop » :

  • Le titre « Particuliers » est au-dessus de l’article 1 (ça ne change pas)
  • Le titre « Particuliers » est à la même abscisse (X) que l’article 1 (ça ne change pas)
  • Le titre « Particuliers » est au-dessus du bloc « Vos services en un clic »
  • Le titre « Particuliers » est à la même abscisse (X) « Vos services en un clic »
  • L’article 1 est au-dessus de l’article 2
  • L’article 1 est à la même abscisse (X) que l’article 2.

Allez, c’est parti !

Des méthodes de bas niveau pour vérifier la position des éléments

A gauche, à droite en haut ou en bas ?

A l’aide d’un enum, on liste seulement deux possibilités, histoire d’homogénéiser les choses dès le début. On n’a pas envie de se demander si c’est le menu X qui est à gauche du formulaire Y ou si c’est le formulaire Y qui est à gauche du menu X…

    public enum POSITION {
        A_GAUCHE_DE,
        AU_DESSUS_DE
    }

On utilise ensuite cet enum dans une méthode de bas niveau. Attention, cette méthode utilise l’objet « Selecteur » ; vous ne le connaissez peut-être pas encore, mais nous vous recommandons d’en créer un pour vos projets (pour plus d’infos, rendez-vous sur ce précédent article, qui explique les avantages du Selecteur).

On vérifie 3 choses dans cette méthode :

  • Premièrement, que les deux éléments existent
  • Deuxièmement, qu’il y a au moins un élément du même type que l’élément 1 dans la position souhaitée par rapport à l’élément 2
  • Troisièmement, que l’élément 1 fait partie de ces éléments

A chaque vérification son message d’erreur spécifique.

Attention, la méthode ne vérifie pas si l’élément 1 est le seul à répondre au critère, ni s’il est le plus proche. A vous de voir si ce niveau de contrôle vous suffit, ou si vous souhaitez le renforcer.

    public void verifierPosition(String tagElement1, Selecteur element1, POSITION position, Selecteur element2){
        // Vérification 1
        Assert.assertTrue(element1.getNom() + " aurait dû être présent(e)", driver.findElements(element1.getChemin()).size() != 0);
        Assert.assertTrue(element2.getNom() + " aurait dû être présent(e)", driver.findElements(element2.getChemin()).size() != 0);

        // Vérification 2
        List<WebElement> elementsMemeTypeMemePositionRelative = null;
        if(position == POSITION.A_GAUCHE_DE) {
            elementsMemeTypeMemePositionRelative = driver.findElements(withTagName(tagElement1).toLeftOf(element2.getChemin()));
        } else if (position == POSITION.AU_DESSUS_DE) {
            elementsMemeTypeMemePositionRelative = driver.findElements(withTagName(tagElement1).above(element2.getChemin()));
        }

        Assert.assertTrue("au moins un élément " + tagElement1 + " aurait dû être présent à la position relative souhaitée (" + position.name() + ") par rapport à l'élément suivant : " + element2.getNom() + ")",
                elementsMemeTypeMemePositionRelative.size() >= 1);

        // Vérification 3
        WebElement webElement1 = driver.findElement(element1.getChemin()); //
        Assert.assertTrue(element1.getNom() + " aurait dû être affiché(e) dans la bonne position (" + position.name() + ") par rapport à l'élément suivant : " + element2.getNom(), elementsMemeTypeMemePositionRelative.contains(webElement1));
    }

Au passage, avez-vous repéré les méthodes Selenium 4, toLeftOf() et above() ? 🙂

Libre à vous ensuite de surcharger cette méthode de bas niveau afin d’améliorer la lisibilité de votre code :

    public void verifierElementAGaucheDe(String tagElement1, AbstractPage.Selecteur element1, AbstractPage.Selecteur element2){
        verifierPosition(tagElement1, element1, AbstractPage.POSITION.A_GAUCHE_DE, element2);
    }

    public void verifierElementAuDessusDe(String tagElement1, AbstractPage.Selecteur element1, AbstractPage.Selecteur element2){
        verifierPosition(tagElement1, element1, AbstractPage.POSITION.AU_DESSUS_DE, element2);
    }

Même abscisse ou même ordonnée

On commence encore d’abord par un enum pour déclarer les deux axes possibles :

    public enum AXE {
        ABSCISSE_X,
        ORDONNEE_Y
    }

On a encore 3 vérifications :

  • Les deux éléments existent
  • Il y a au moins un élément du même type que l’élément 1 qui ne soit ni à gauche ni à droite (ou ni en haut ni en bas) de l’élément 2
  • L’élément 1 fait partie de ces éléments
public void verifierMemeAxe(AXE axe, String tagElement1, AbstractPage.Selecteur element1, Selecteur element2){
    Assert.assertTrue(element1.getNom() + " aurait dû être présent(e)", driver.findElements(element1.getChemin()).size() != 0);
    Assert.assertTrue(element2.getNom() + " aurait dû être présent(e)", driver.findElements(element2.getChemin()).size() != 0);

    List<WebElement> elementsMemeType = driver.findElements(withTagName(tagElement1));
    if(axe == AXE.ABSCISSE_X){
        // Là, on liste les éléments à gauche et à droite de notre élément (ceux qui ont un X différent)
        List<WebElement> elementsAGauche = driver.findElements(withTagName(tagElement1).toLeftOf(element2.getChemin()));
        List<WebElement> elementsADroite = driver.findElements(withTagName(tagElement1).toRightOf(element2.getChemin()));
        // On supprime de notre liste initiale tous les élements qui ont un X différent de notre élément
        elementsMemeType.removeAll(elementsAGauche);
        elementsMemeType.removeAll(elementsADroite);
    } else if (axe == AXE.ORDONNEE_Y) {
        List<WebElement> elementsAuDessus = driver.findElements(withTagName(tagElement1).above(element2.getChemin()));
        List<WebElement> elementsEnDessous = driver.findElements(withTagName(tagElement1).below(element2.getChemin()));
        elementsMemeType.removeAll(elementsAuDessus);
        elementsMemeType.removeAll(elementsEnDessous);
    }
    Assert.assertTrue("au moins un élément " + tagElement1 + " aurait dû être présent à la même " + axe.name() + " que l'élément suivant : " + element2.getNom() + ")", elementsMemeType.size() >= 1);
    WebElement webElement1 = driver.findElement(element1.getChemin());
    Assert.assertTrue(element1.getNom() + " aurait dû être affiché(e) avec la même " + axe.name() + " que l'élément suivant : "
            + element2.getNom(), elementsMemeType.contains(webElement1));
}

Et les méthodes « surchargeantes » :

    public void verifierElementMemeOrdonnee(String tagElement1, Selecteur element1, Selecteur element2){
        verifierMemeAxe(AXE.ORDONNEE_Y, tagElement1, element1, element2);
    }

    public void verifierElementsMemeAbscisse(String tagElement1, Selecteur element1, Selecteur element2){
        verifierMemeAxe(AXE.ABSCISSE_X, tagElement1, element1, element2);
    }

Résultat final !

On a désormais tout ce qu’il nous faut pour effectuer automatiquement les vérifications évoquées plus haut. Et les voilà, au sein d’un objet page (encore une fois si ce concept ne vous parle pas, rendez-vous sur cet article qui explique l’intérêt d’avoir des objets page) :

public class ServicePublicPage extends AbstractPage {

    private final Selecteur ongletParticuliersMenu = new Selecteur("l'onglet 'Particuliers' du menu", By.xpath("//a[contains(., 'Particuliers')]"));
    private final Selecteur titreParticuliers = new Selecteur("le titre 'Particuliers'", By.id("page-title"));
    private final Selecteur blocVosServices = new Selecteur("le bloc intitulé 'Vos services en un clic'", By.id("block-gnc-services-services-menu"));
    private final Selecteur blocSanteSocial = new Selecteur("le bloc intitulé 'Santé - Social'", By.xpath("//article[contains(., 'Santé - Social')]"));
    private final Selecteur blocTravail = new Selecteur("le bloc intitulé 'Travail'", By.xpath("//article[contains(., 'Travail')]"));

    public void accesPartieParticuliers(){
        clickElement(ongletParticuliersMenu);
    }

    public void verifierMenuDesktop(){
        driver.manage().window().maximize();
        verifierElementAuDessusDe("h1", titreParticuliers, blocSanteSocial);
        verifierElementsMemeAbscisse( "h1", titreParticuliers, blocSanteSocial);
        verifierElementMemeOrdonnee( "h1", titreParticuliers, blocVosServices);
        verifierElementAGaucheDe("h1", titreParticuliers, blocVosServices);
        verifierElementMemeOrdonnee( "article", blocSanteSocial, blocTravail);
        verifierElementAGaucheDe( "article", blocSanteSocial, blocTravail);
    }


    public void verifierMenuDesktop_demiEcran(){
        driver.manage().window().maximize();
        int largeurEcran = driver.manage().window().getSize().width;
        int hauteurEcran = driver.manage().window().getSize().height;
        driver.manage().window().setSize(new Dimension(largeurEcran/2, hauteurEcran));
        verifierElementAuDessusDe("h1", titreParticuliers, blocSanteSocial);
        verifierElementsMemeAbscisse( "h1", titreParticuliers, blocSanteSocial);
        verifierElementAuDessusDe("h1", titreParticuliers, blocVosServices);
        verifierElementsMemeAbscisse( "h1", titreParticuliers, blocVosServices);
        verifierElementAuDessusDe( "article", blocSanteSocial, blocTravail);
        verifierElementsMemeAbscisse( "article", blocSanteSocial, blocTravail);
    }

}

Maintenant, vous n’avez plus qu’à utiliser ces méthodes dans vos tests !

public class testServicePublicNC extends AbstractTest {

    @DisplayName("Vérifier l'ordre du menu en mode desktop")
    @Test
    public void verifierOrdreMenu_desktop(){
        ServicePublicPage servicePublicPage = new ServicePublicPage();
        servicePublicPage.accesPartieParticuliers();
        servicePublicPage.verifierMenuDesktop();
    }

    @DisplayName("Vérifier l'ordre du menu en mode desktop - demi-écran")
    @Test
    public void verifierOrdreMenu_desktop_demiEcran(){
        ServicePublicPage servicePublicPage = new ServicePublicPage();
        servicePublicPage.accesPartieParticuliers();
        servicePublicPage.verifierMenuDesktop_demiEcran();
    }

}

Bonus : si vous devez attendre avant de monter de version

N’oublions pas que Selenium 4 est encore en version Alpha. En attendant qu’une version stable soit livrée, et si vous en avez besoin dans vos projets actuels, il est déjà possible de réaliser les vérifications évoquées dans l’article. Cet article fournit un tutoriel très clair, en Java également.

Test Automation University en 12 questions – réponses

1) Qu’est-ce que Test Automation University ?

Test Automation University est un service en ligne gratuit de formation à l’automatisation des tests. Il est rapidement devenu un grand classique dans le domaine de l’automatisation des tests.

2) Comment se déroulent les formations ?

Les cours se présentent comme des séries de vidéos et de textes, qui donnent lieu à des QCM réguliers. Des références complémentaires sont citées au sein des cours de façon à donner des pistes d’approfondissement.

Attention, vous ne pourrez plus accéder au contenu des questions une fois que vous aurez obtenu les résultats des QCM !

3) Les formations Test Automation sont-elles certifiantes ?

Un certificat nominatif est généré à la fin de chaque formation. La notation est généreuse, donc ne surestimez pas la valeur de tels certificats ! Toutefois, ils seront certainement utiles pour mettre en valeur la curiosité d’un candidat : si vous êtes en démarche de reconversion (de développeur à QA par exemple), c’est une piste intéressante qui donnera du corps à votre CV. N’oubliez pas également de jeter aussi un œil à notre article « Comment devenir testeur logiciel » !

4) Combien de temps durent les formations ?

C’est très variable, mais sachez que certains cours peuvent être suivis en entier en moins d’une heure. Par exemple, « AI for Element Selection: Erasing the Pain of Fragile Test Scripts » se compose de 3 vidéos pour un total d’environ 30 minutes.

5) Qui sont les formateurs ?

Là, c’est une merveilleuse surprise. La plateforme est un projet porté par la société Applitools, on pourrait donc s’attendre à du contenu austère et dogmatique issu d’un quelconque éditeur en mal de visibilité. Ce n’est pas du tout le cas. Les formateurs sont tous des experts reconnus dans le monde du test, et sont indépendants les uns des autres. Comme indiqué dans le « cours » de présentation de la plateforme, l’esprit du site est de mettre en valeur une grande diversité de façons de voir l’automatisation des tests. Et ça fonctionne !

De notre côté, nous avons reconnu avec plaisir quelques-uns d’entre eux, dont Jason Arbon, un des co-auteurs de How Google Tests Software (dont nous parlions dans notre article sur les plans de test), et Dave Haeffner, auteur du blog Elemental Selenium, dont nous recommandons la newsletter.

6) Que faut-il attendre du Slack associé ?

Fin juin 2019, ce Slack comptait non moins de 1591 inscrits, pour un total de 6470 messages répartis sur 25 chaînes.

Certaines chaînes ont des thématiques générales, d’autres portent sur des cours de la plateforme. Les formateurs répondent directement aux questions des apprenants.

Quelques questions générales de testing donnent lieu à des discussions entre testeurs (sur des choix d’outils notamment). Certains partagent des ressources en rapport avec le contenu des cours (ce qui nous a permis notamment de découvrir ce joli petit exercice d’entraînement aux sélecteurs CSS, CSS Diner). Cette plateforme deviendra certainement plus active au fil du temps ; en tout état de cause, il y règne déjà une ambiance conviviale et sympathique.

Une chaîne est naturellement dédiée… aux petites anomalies présentes sur la plateforme !

7) Les formations sont-elles accessibles aux débutants ?

Les cours proposés par Test Automation University peuvent être classés par niveau de difficulté ou par thématique. Les cours débutants sont accessibles aux « grands débutants », surtout si l’on tient compte de la communauté Slack qui peut être sollicitée en cas de problème.

Par exemple, le cours « Web Element Locator Strategies » (un sujet sur lequel nous vous avons mis à l’épreuve !) revient aux fondamentaux : structure des pages web, rôle du HTML, du CSS et du JavaScript, différence entre éléments et sélecteurs… Ce qui en fait un contenu accessible à tous.

8) La plateforme est-elle gamifiée ?

A un niveau basique, oui, la plateforme propose une petite surcouche de gamification qui plaira à certains. Au fur et à mesure qu’il gagne des crédits en répondant correctement aux questionnaires, l’utilisateur progresse de niveau en niveau (de « licorne » à « kraken »). En revanche, ces niveaux ne donnent lieu à aucun privilège (fonctionnalités supplémentaires par exemple).

Sur la page de l’utilisateur sont affichés les badges (un badge par cours, plus à l’heure actuelle un badge spécial) ainsi qu’un camembert représentant l’avancée globale de l’utilisateur sur la plateforme.

9) Les vidéos ont-elles une transcription ?

Oui, et elles sont vraiment bien faites. Elles ne contiennent pas seulement le script que l’on peut entendre dans la vidéo, mais aussi le code qui s’affiche à l’écran (au format texte avec une bonne mise en forme).

10) Test Automation University est-il disponible en français ?

Tout le contenu du site est pour le moment en anglais.

11) Est-ce gratuit ?

Oui, et sans publicité envahissante. A l’heure actuelle il n’y a qu’un lien sponsorisé en bas de la page d’accueil, et les vidéos hébergées sur Youtube vous occasionneront peut-être quelques pubs par-ci par-là.

12) Les contenus sont-ils récents ?

À l’heure où nous écrivons cet article, oui ! Le service a été lancé le 1er premier janvier 2019, avec un premier cours : « Setting the Foundation for Successful Test Automation ».

La plateforme est en effervescence, de nouveaux cours apparaissent quasiment chaque semaine.

Nous avons été enchantés de découvrir ce site et lui souhaitons de rencontrer tout le succès qu’il mérite.

Les xPath et les tableaux : 8 exercices pour se perfectionner

On ne le dira jamais assez, rien ne surpasse les id dans les techniques d’identification des objets dans un DOM. C’est le plus simple et aussi le plus rapide à trouver par Selenium. Mais parfois (souvent) on ne peut pas faire autrement que d’écrire des xPath tellement complexes qu’ils frisent le write-only. Ces moments de solitude arrivent souvent lorsqu’on interagit avec des tableaux. On met 10 minutes à trouver la bonne formule et deux semaines après on ne s’en souvient plus. Nous voulons que ce temps soit révolu !

Voici donc 8 défis pour vous entraîner à écrire des xPath pour attraper des éléments dans des tableaux. Pour vérifier vos réponses nous vous conseillons l’outil CSS and XPath checker.

Les réponses se trouvent en bas de l’article.

xPath vs tableau HTML

Dans cet exercice, nous nous baserons sur le tableau suivant (vous pourrez valider vous-mêmes les formules sur la présente page) :

Fruit Description Prix au kilo (XPF)
Pomme-liane Un feu d’artifice de saveurs acidulées 700
Banane poingo Le compromis entre la patate et la banane 500
Pomme-cannelle De loin, ressemble à un artichaut 630
Letchi Ce n’est plus la saison 700
Noix de coco Son germe est délicieux 350
Chouchoute Oups, ce n’est pas un fruit 300

 

Sous chaque question se trouve une copie d’écran du tableau avec le résultat attendu en surbrillance.

Exercices de xPath pour identifier des éléments dans le tableau

1) Ecrire un xPath pour récupérer la deuxième cellule qui contient « Pomme ».

2) Ecrire un xPath pour récupérer la première case des lignes dont la colonne 3 contient la chaîne 700.

3) Ecrire un xPath pour récupérer la deuxième case après les cellules contenant « Pomme-cannelle ».

4) Ecrire un xPath pour récupérer les cases qui contiennent des prix entre 300 (inclus) et 630 (exclu).

5) En hommage à Georges Perec, écrire un xPath pour récupérer les cases qui ne contiennent pas de « e » minuscule (cases de l’entête du tableau comprises).

6) Ecrire un xPath pour récupérer les lignes qui contiennent une case dont le texte commence par « Oups ».

7) Ecrire un xPath pour récupérer les cellules du tableau (hors entête) qui contiennent la chaîne « de », qu’elle soit en minuscules ou en majuscules.

8) Allez, un bien compliqué pour finir. Ecrire un xPath pour récupérer les noms des fruits dont la description contient le texte « est » et dont le prix est entre 300 (inclus) et 630 (exclu).

Alors, combien d’exercices avez-vous réussi à faire ? 😀

Rappel de bonnes pratiques

Attention, même s’il est préférable d’avoir des sélecteurs simples à comprendre, ne faites pas reposer la lisibilité de votre projet d’automatisation sur la lisibilité de vos sélecteurs. Envisagez l’adoption de l’objet Selecteur tel que nous détaillions dans notre article sur la lisibilité des logs Selenium :

public class Selecteur {
   public String nom;
   public By chemin;

   public Selecteur(String nom, By chemin){
      this.nom = nom;
      this.chemin = chemin;
   }

   public String getNom(){
      return nom;
   }

   public By getChemin(){
      return chemin;
   }
}

Avec comme exemple d’application :

protected void clickElementTableau(int ligne, int colonne) {
    Selecteur cellule = new Selecteur("la cellule située sur la ligne " + ligne + " et la colonne " + colonne + " du tableau", By.xpath("//tr[" + ligne + "]/td[" + colonne + "]"));
    logger.info("Clic sur " + cellule.getNom());
    driver.findElement(cellule.getChemin()).click();
}

En sortie, vous aurez des logs en langage naturel, par exemple : « Clic sur la cellule située sur la ligne 3 et la colonne 4 du tableau ».

Rappels sur les xPath

  • les xPath sont en base 1, c’est-à-dire que le premier élément d’une série a comme index 1, contrairement, par exemple, aux tableaux et aux listes Java dont le premier élément a pour index 0.
  • les xPath sont sensibles à la casse quand on fait une recherche sur du texte ou un attribut

Solutions

Il existe souvent plusieurs solutions possibles, celles ci-dessous ne sont que des possibilités.

1. Un xPath pour récupérer la deuxième cellule qui contient « Pomme » :

(//td[contains(., 'Pomme')])[2]

2. Un xPath pour récupérer la première case des lignes dont la colonne 3 contient la chaîne 700 :

//td[3][contains(., '700')]//../td[1]

3. Un xPath pour récupérer la deuxième case après la cellule qui contient « Pomme-cannelle » :

//td[contains(., 'Pomme-cannelle')]/following-sibling::td[2]

4. Un xPath pour récupérer les cases qui contiennent des prix entre 300 (inclus) et 630 (exclu) :

//td[. >= 300 and 630 > .]

5. Un xPath pour récupérer les cases qui ne contiennent pas de « e » minuscule (cases de l’entête du tableau comprises) :

//td[not(contains(., 'e'))] | //th[not(contains(., 'e'))]

6. Un xPath pour récupérer les lignes qui contiennent une case dont le texte commence par « Oups » :

//td[starts-with(., 'Oups')]/parent::tr

7. Un xPath pour récupérer les cellules du tableau (hors entête) qui contiennent la chaîne « de », qu’elle soit en minuscules ou en majuscules :

//td[contains(translate(., 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz'), 'de')]

Conseil : si possible encapsuler cette transformation de casse dans une fonction.

8. Un xPath pour récupérer les noms des fruits dont la description contient le texte « est » et dont le prix est entre 300 (inclus) et 630 (exclu).

//td[. >= 300 and 630 > .]/preceding-sibling::td[contains(., 'est')]/preceding-sibling::td

Même exercice pour les sélecteurs CSS

Mise à jour du 24 juin 2019 : nous avons découvert, via un utilisateur du Slack de la Test Automation University, un exercice en ligne pour s’entraîner à écrire des sélecteurs CSS. Un petit jeu interactif réjouissant et très bien fait : découvrez CSS Diner !

Tests autos d’applis lourdes : le défi du gratuit

Vous venez du monde de Selenium, vous aimez ce framework gratuit, sa souplesse, la beauté du pattern page-object et son DSL aux petits oignons. Magnifique, mais aujourd’hui vous devez automatiser les tests d’une application lourde.

Il y a quelques années encore, choisir un outil d’automatisation gratuit et open-source pour ce genre de tests était un sérieux défi et présentait de nombreux risques : frameworks peu maintenus, résultats instables… Une solution propriétaire telle qu’UFT pouvait alors s’imposer comme un choix par défaut.

Est-ce différent aujourd’hui ? Nous pensons que certaines solutions sont désormais assez mûres pour être choisies au sein de projets de test ambitieux.

Pywinauto : go !

Ce nom incongru est la contraction de Python, Windows et Automation. Ce framework de test a vu le jour en 2006 (!), et donne lieu à des releases régulières depuis 2015. La version 1.0 n’est pas encore sortie (modestie de la part de Vasily Ryabov, développeur de Pywinauto ?) mais à l’utilisation, l’outil est parfaitement stable.

Avantages de Pywinauto

Utilisable dans tout IDE Python, la solution permet à l’utilisateur d’architecturer les projets de tests comme bon lui semble. Nous avons opté pour le pattern page-object, un grand classique qui permet de maintenir facilement les tests.

Principes

Identification des objets pour Pywinauto

L’identification des objets d’application Windows peut se faire grâce à des outils comme Inspect.exe, fourni avec le SDK Windows. UI Spy peut aussi être envisagé, mais il n’est plus maintenu par Microsoft. Cependant, à l’usage, nous l’avons trouvé plus rapide.

Grâce à ces utilitaires, il est possible de connaître les paramètres des objets, et donc de les identifier pour interagir avec eux (voir la liste des paramètres gérés par Pywinauto).

Interaction avec les objets avec Pywinauto

Dans l’exemple ci-dessous, nous déclarons ainsi une page ainsi que quelques objets, en utilisant au besoin plusieurs paramètres.

class AccueilPage:

    def __init__(self, test):
        self.ECRAN_ACCUEIL = test.app.window(title='Ma super appli - Accueil')
        self.INPUT_NOM = self.ECRAN_ACCUEIL.child_window(control_type="Edit", auto_id='23', found_index=0)
        self.INPUT_PRENOM = self.ECRAN_ACCUEIL.child_window(control_type="Edit", auto_id='24', found_index=0)

Dans l’architecture que nous avons mise en place, un test doit être invoqué au moment de l’appel du constructeur de la page. Ce test est initialisé au début de chaque scénario et correspond à la classe suivante :

class Test:
    app = Application(backend='uia')

    def __init__(self):
        parser = argparse.ArgumentParser()
        parser.add_argument("--log", help="enable logging", type=str, required=False)
        args = parser.parse_args()

        actionlogger.enable()
        logger = logging.getLogger('pywinauto')
        if args.log:
            logger.handlers[0] = logging.FileHandler(args.log)

        self.app = Application(backend='uia').start(r'C:cheminversmasuperappli.EXE')

Selon la façon dont l’application a été développée, certains objets ont un titre qui est affiché dans l’arborescence, ici d’UI Spy :

Dans cet exemple, on peut interagir avec le bouton « Appliquer » en utilisant le mot-clé title :

test.app.window(title='Appliquer')

Points d’attention

Certains objets complexes, par exemple des cellules de tableaux spécifiques, n’apparaissent pas toujours dans l’arborescence. Ce n’est pas nécessairement un problème provenant de Pywinauto, mais il faut garder en tête des solutions de contournement, par exemple la reconnaissance d’image que l’on trouve entre autres avec Sikulix.

Verdict

De notre côté, c’est un go ! Pywinauto a toute sa place au sein d’un POC, et a en outre l’avantage d’avoir un support efficace. Vasily Ryabov est très réactif sur Github aussi bien que sur StackOverflow, ce qui permet d’aller au-delà des blocages éventuels. EDIT du 19/20/2020 : et c’est toujours vrai en 2020 !

Winium : no go !

Framework basé sur Selenium et adapté aux applications Windows, la promesse de Winium est (était) séduisante… Malheureusement, il n’est plus maintenu et certains bugs empêchent de s’en servir efficacement. Nous vous expliquons cependant ce qui nous a plu et déplu dans cet outil, qui reste une excellente initiative.

Avantages de Winium

Pour un habitué de Selenium, la transition se fait en douceur ; les mêmes méthodes peuvent être utilisées dans la plupart des cas.

Vous ne rêvez pas ! On dirait bien un test Selenium…

Problèmes rencontrés

Identification des éléments

Afin d’interagir avec les objets de l’application à tester, plusieurs méthodes sont possibles (mais moins que pour Pywinauto). De la plus à la moins robuste, on peut procéder :

  • Par Id
  • Par Name
  • Par ClassName
  • Par Xpath

Les trois premiers paramètres, que l’on peut trouver avec les outils mentionnés précédemment, sont les plus pratiques à utiliser. Malheureusement, ils ne sont pas toujours renseignés. Il faut  alors avoir recours à la recherche par xPath, ce qui peut être plus difficile dans ce contexte que dans celui d’un DOM HTML.

Quelle que soit la méthode utilisée, les éléments semblent être trouvés d’autant plus lentement que l’interface compte un grand nombre d’objets.

Comme solution de contournement pour accélérer le test, nous avons utilisé Sikulix, avec toutes les questions que cela soulève côté maintenance.

Bug de focus

Nous avons relevé un bug assez ennuyeux : il arrive que l’application cible ne reçoive pas le focus pendant les tests. Pour peu que la fenêtre de l’IDE soit affichée, on se retrouve à taper l’identifiant en lieu et place du script de test.

A part fermer les fenêtres inutiles et réduire la fenêtre de l’IDE après le lancement de la campagne, nous n’avons pas trouvé de solution à ce problème.

Des nouvelles du créateur de Winium

Les logiciels ne poussent pas dans les arbres, en l’occurrence Winium est la création de Nick Abalov, actuellement développeur chez Badoo. Sur Twitter, il a gentiment répondu à notre question « Winium est-il mort ? » :

For Windows Desktop automation you might want to look into https://t.co/2agvjg2Kdj

— Nick Abalov (@NickAb) 20 décembre 2018

<script>

A suivre alors, WinAppDriver présentant cependant la contrainte de nécessiter un environnement Windows 10.

Verdict

Pour nous, c’est donc un no-go. Il est possible de mettre en place de petits projets d’automatisation en utilisant Winium, mais entamer un projet ambitieux avec cet outil serait imprudent.

Et vous, quels frameworks gratuits d’automatisation d’applications lourdes utilisez-vous ?

Gérer les paramètres Jenkins quand on est maniaque (ou flemmard)

Problème : des paramètres Jenkins interdépendants

Il n’est pas rare, quand on construit un build Jenkins avec des paramètres, que ceux-ci dépendent les uns des autres.

Exemple de configuration

Vous avez un paramètre de choix « Type de plat » avec comme valeurs possibles « Entrée », « Plat », « Dessert » et « Après-dessert » (un après-dessert est toujours le bienvenu).

Vous avez un autre paramètre de choix « Plat » avec comme valeurs possibles « Champignons à la grecque », « Spaghettis au roquefort », « Brownie » et « Salade de kiwis ».

Vous avez en tête un certain nombre de règles.

  • Les champignons à la grecque peuvent être commandés en tant qu’entrée ou plat principal
  • Les spaghettis au roquefort sont un plat
  • Il est possible de commander un brownie en dessert, mais pas en après-dessert, car ce ne serait pas raisonnable
  • La salade de kiwis peut être commandée en dessert ou en après-dessert.

Pourquoi cette configuration pose-t-elle problème ?

Possibilité 1 : vous êtes prudent (ou maniaque) et aimeriez interdire certaines combinaisons incohérentes.

Possibilité 2 : vous êtes flemmard et aimeriez gagner un peu de temps au moment de lancer un build.

Heureusement que la vie est bien faite et qu’il existe un plugin rien que pour vous.

Solution : Active Choices, un plugin Jenkins pour créer des conditions entre paramètres

Autrefois appelé Uno-Choice, le plugin Active Choice est gratuit et disponible directement depuis le gestionnaire de plugins de Jenkins.

Exemple d’utilisation d’Active Choices

Pour le cas énoncé, nous allons ajouter au job un paramètre de choix. Veillons simplement à ce que son nom soit en un seul mot, en écrivant « Type de plat » en camelcase. C’est important pour pouvoir ensuite utiliser ce nom comme une variable.

Maintenant, au lieu de créer un autre paramètre de choix classique, ajoutons un paramètre de type « Active Choices Reactive Parameter ».

Il faut maintenant cocher la case « Groovy Script », qui va nous permettre d’écrire nos règles. Ici, le script correspondant est le suivant :

if (TypeDePlat.equals("Entrée")) {
    return ["Champignons à la grecque"]
} else if (TypeDePlat.equals("Plat de résistance")) {
    return ["Champignons à la grecque", "Spaghettis au roquefort"]
} else if (TypeDePlat.equals("Dessert")) {
    return ["Brownie", "Salade de kiwis"]
} else if (TypeDePlat.equals("Après-dessert")) {
    return ["Salade de kiwis"]
} else {
    return ["Des petits cailloux ramassés dans l'allée"]
}

On indique une valeur par défaut dans le Fallback Script (par prudence, veiller à ce qu’elle soit cohérente avec la première valeur du paramètre de choix standard) :

return ["Champignons à la grecque"]

Maintenant, il faut simplement préciser à quel paramètre on se réfère.

Après sauvegarde de la configuration, lorsqu’on lance un build avec des paramètres, la liste déroulante des plats se met à jour en fonction de la valeur choisie dans la liste des types de plats. Pratique !

Ordre d’apparition des paramètres

Si vous êtes vraiment maniaque, vous remarquerez que les paramètres s’affichent dans la liste déroulante dans le même ordre que celui du script, et que par défaut, c’est le premier élément de la liste qui sera choisi.

Pour modifier cette valeur sans changer l’ordre alphabétique, au lieu de mettre l’élément voulu au début de la liste, il suffit de lui apposer « :selected« , comme ci-après :

return ["Champignons à la grecque", "Spaghettis au roquefort:selected"]

Conclusion

Le plugin offre de nombreux paramétrages possibles ; prenez le temps de les essayer, ça en vaut la peine !

Vous aimerez peut-être…

SonarQube met son grain de sel dans Gitlab !

Cas d’usage : JSoup et Gatling pour repérer les liens morts

L’automatisation des tests, c’est votre dada ? Voilà une ressource qui en parle en long, en large et en travers !

Logs Selenium : passez niveau maître

Des logs Selenium lisibles pour tous

Nous parlions de ce syndrome dans un précédent article ; le testeur chargé de l’automatisation des tests est parfois le seul à comprendre ses logs (on a appelé ça la logopathie). Cela réduit l’utilité des automates qui se retrouvent auréolés d’un mystère inutile.

Pour poursuivre dans cette série de bonnes pratiques d’automatisation des tests, nous vous proposons aujourd’hui plusieurs approches pour améliorer vos logs Selenium, sans le moindre framework hipster, juste avec du bon vieux Java. Nous utiliserons un système de logging des plus classiques, à savoir Log4J2, réglé sur la verbosité « INFO ». Libre à vous ensuite d’exploiter ces logs dans l’outil de reporting de votre choix (Allure par exemple). Allez, c’est parti !

Le script Selenium niveau débutant : rien que les logs Java

Exemple de script Selenium

Voici un script très optimiste qui vérifie sur un célèbre site de vente calédonien que la première Peugeot 107 à vendre coûte 10 000 francs pacifiques ou moins.

import org.junit.After;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.Keys;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import java.util.concurrent.TimeUnit;

public class TestLogs {

    WebDriver driver;

    @Before
    public void setUp() {
        System.setProperty("webdriver.chrome.driver", "webdrivers/chromedriver.exe");
        driver = new ChromeDriver();
        driver.manage().timeouts().implicitlyWait(15, TimeUnit.SECONDS);
    }

    @Test
    public void testLogs(){
    driver.get("https://automobiles.nc/");
        WebElement element = driver.findElement(By.id("recherche"));
        element.sendKeys(Keys.DELETE);
        element.sendKeys("107");
        driver.findElement(By.cssSelector("input[value='OK']")).click();
        driver.findElement(By.xpath("//a[contains(., 'Offre')]")).click();
        driver.findElement(By.xpath("(//table[contains(@href, 'detail_annonce')]//img)[1]")).click();
        Assert.assertTrue("ERREUR : le prix affiché est supérieur à " + 10000, Integer.parseInt(driver.findElement(By.xpath("//div[contains(@id, 'detail')]")).getText(). split("Prix : ")[1].split(" F cfp")[0]. replaceAll("\s+", "")) < 10000);
    }

    @After
    public void tearDown(){
        driver.quit();
    }
}

Problèmes du script Selenium

Comment on va maintenir ça ?

Ce qui saute déjà aux yeux avec ce script, c’est qu’il enfreint la règle de séparation du test et des objets pages. Si le Page Object Model ne vous éveille aucun souvenir, allez jeter un œil à cet article.

Ecrivez tous vos tests de cette façon et vous obtiendrez un magnifique plat de spaghettis impossible à maintenir !

Mais ce qui nous dérange le plus ici, c’est qu’en cas d’échec, on n’aura pas beaucoup d’informations

Exemples de logs cryptiques

Si la première Peugeot 107 affichée coûte plus de 10 000 XPF, on se retrouvera avec ces logs :

java.lang.AssertionError: ERREUR : le prix affiché est supérieur à 10000

at org.junit.Assert.fail(Assert.java:88)
 at org.junit.Assert.assertTrue(Assert.java:41)
 at TestLogs.testLogs(TestLogs.java:33)
 // [...] Et encore plein de lignes qu'on vous épargnera

Et rien avant ce problème d’AssertionError. Là, on a bien le test en tête, on comprend ce qui s’est passé. Cela dit, dans 6 mois, on ne saura plus ce qui était censé coûter 10 000 XPF maximum, sur quel site, etc…

Et si jamais le bouton de recherche n’est pas trouvé, les logs remontent cela, ce qui est moins parlant :

*** Element info: {Using=id, value=recherche}

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
// [...]

Heureusement que le champ de recherche a un id et que celui-ci est explicite, mais ce n’est pas toujours le cas… Par exemple, sur le site d’Amazon, le champ de recherche a pour id « twotabsearchtextbox », ce qui est un peu moins compréhensible.

Le script Selenium niveau supérieur : chaque étape est logguée

Dans le bloc ci-dessous, le test a bien changé, il répond maintenant au pattern du Page Object Model. Il est beaucoup plus court, et surtout il est plus lisible grâce à des noms de méthodes explicites. Son setup et son teardown sont remontés d’un cran et se trouvent dans une nouvelle classe, « AbstractTest », dont hérite le test ; de cette façon, ils pourront être utilisés dans tous les tests.

La page invoquée, AnnoncesNcPage, a également son propre objet, qui contient ses propres méthodes.

Et les méthodes de bas niveau utilisées dans l’objet AnnoncesNcPage sont elles-mêmes remontées dans une classe mère, AbstractPage.

De cette façon, on respecte les célébrissimes principes DRY (don’t repeat yourself) et KISS (keep it super simple).

Le nouveau test Selenium

import org.junit.Test;
import pages.AnnoncesNcPage;
import utils.AbstractTest;

public class TestLogs extends AbstractTest {

    @Test
    public void testLogs() {
        accesURL("https://automobiles.nc/");
        AnnoncesNcPage annoncesNC = new AnnoncesNcPage(this);
        annoncesNC.rechercherProduit("107");
        annoncesNC.accesAuxOffres();
        annoncesNC.classerParPrix();
        annoncesNC.deplierAnnonceNumero(1);
        annoncesNC.verifierPrixInferieurOuEgalA(10000);
    }

}

Les méthodes de haut et de bas niveau

Toutes les méthodes de bas niveau donnent lieu à une ligne de log. Les méthodes de vérification donnent lieu à un log en cas d’échec. Un exemple avec la méthode qui permet de classer les produits par prix :

// Dans AnnoncesNcPage. On trouve les objets et les méthodes spécifiques à la page.

private final By BTN_CLASSER_PAR_PRIX = By.xpath("(//a[contains(@href, 'orderBy=prix')])[1]");
public void classerParPrix(){
   clickElement(BTN_CLASSER_PAR_PRIX);
}

[...]
// Dans AbstractPage. On trouve des méthodes qui pourraient servir à toutes les pages web du monde. Des vérifications sont faites avant chaque interaction, pour vérifier que l'élément concerné est bien présent, et logger ce problème le cas échéant.

protected int timeOut = 5;

protected void clickElement(By by) {
 logger.info("Clic sur l'élément '" + getPathFromBy(by) + "'");
 assertElementPresent(by);
 driver.findElement(by).click();
}

protected String getPathFromBy(By by){
    return by.toString().split(": ")[1]; // On a choisi de faire ce split pour gagner en concision, mais vous aurez peut-être envie de conserver le type de sélecteur.
}

public void assertElementPresent(By by) {
    if(!isElementPresent(by)){
        logger.error("ERREUR : '" + getPathFromBy(by) + "' n'a pas été trouvé(e) sur la page.");
    }
    assertTrue(isElementPresent(by));
}

public boolean isElementPresent(By by) {
    boolean isElementPresent = false;
    int time = 0;
    while (!isElementPresent && time < timeOut) {
        if (isElementPresentNow(by)) {
            isElementPresent = true;
        } else {
            isElementPresent = false;
        }
        sleep(1);
        time++;
    }
    return isElementPresent;
}

public boolean isElementPresentNow(By by) {
    driver.manage().timeouts().implicitlyWait(0, TimeUnit.MILLISECONDS);
    boolean isElementPresent = (driver.findElements(by).size() != 0);
    driver.manage().timeouts().implicitlyWait(timeOut, TimeUnit.MILLISECONDS);
    return isElementPresent;
}

Les nouveaux logs

Désormais, les logs ressemblent maintenant à ça :

Accès à l'URL https://automobiles.nc/
Renseignement du texte '107' dans l'élément 'recherche'
Clic sur l'élément 'input[value='OK']'
Clic sur l'élément '//a[contains(., 'Offre')]'
Clic sur l'élément '(//a[contains(@href, 'orderBy=prix')])[1]'
Clic sur l'élément '(//table[contains(@href, 'detail_annonce')]//img)[1]'
ERREUR : le prix affiché est supérieur à 10000

On comprend un peu mieux ce qui s’est passé. Un testeur n’ayant pas lui-même écrit ce test peut, en se concentrant un peu, retracer le scénario. Ca peut suffire, mais une fois encore, si on veut partager nos logs, on se retrouve dépendants de la clarté des sélecteurs.

Le script Selenium niveau maître : des logs compréhensibles par tous

Jusqu’à maintenant, rien de bien original. Mais nous voulons maintenant aller un peu plus loin, en permettant à toute personne de comprendre parfaitement les logs, sans avoir besoin du moindre bagage HTML et CSS. On pense par exemple aux intervenants fonctionnels qui auraient besoin de lancer les tests automatisés en autonomie et d’analyser leurs résultats. Chaque étape sera détaillée en langage naturel, joliment et proprement, aussi bien que si on les avait décrites nous-mêmes. A ce stade, les logs du test seront aussi clairs que possible, et surtout à peu de frais. C’est parti !

Ce que nous n’allons pas faire

Une solution serait d’étoffer chaque méthode de la classe AnnoncesNcPage par un log spécifique.

public void classerParPrix(){
   logger.info("Classement des produits par prix");
   clickElement(BTN_CLASSER_PAR_PRIX);
}

Pourquoi pas, si vous avez le temps d’écrire ces logs et que vous vous engagez à les maintenir. Mais on va partir du principe que vous voulez gagner du temps et faire au plus simple.

Notre proposition : bye bye le By

Pour identifier et interagir avec les éléments de la page (boutons, liens, champs…), Selenium propose une classe dédiée : By. Elle permet de les sélectionner par xpath, nom de classe CSS, sélecteur CSS, id, texte de lien hypertexte (ou partie de ce texte), name, balise html…

private final By BTN_CLASSER_PAR_PRIX = By.xpath("(//a[contains(@href, 'orderBy=prix')])[1]");

Mais nous allons laisser tomber ce bon vieux By, ou plutôt l’améliorer pour la beauté de vos logs. Nous allons passer par une nouvelle classe, que nous allons appeler « Selecteur ».

// Dans AbstractPage

public class Selecteur {
   public String nom;
   public By chemin;

   public Selecteur(String nom, By chemin){
      this.nom = nom;
      this.chemin = chemin;
   }

   public String getNom(){
      return nom;
   }

   public By getChemin(){
      return chemin;
   }
}

Remplacement des By par des Selecteurs

Dans les méthodes

Maintenant, on va modifier nos méthodes de bas niveau qui utilisent la classe By et en la remplaçant par la classe Selecteur. Par exemple :

// Dans AbstractPage

protected void clickElement(Selecteur selecteur) {
    logger.info("Clic sur " + selecteur.getNom());
    assertElementPresent(selecteur);
    driver.findElement(selecteur.getChemin()).click();
}
protected String getPathFromBy(Selecteur selecteur){
    return selecteur.getChemin().toString().split(": ")[1];
}
public void assertElementPresent(Selecteur selecteur) {
    if(!isElementPresent(selecteur.getChemin())){
        logger.error("ERREUR : " + selecteur.getNom() +
                " n'a pas été trouvé(e) sur la page. " +
                " (sélecteur : '" + getPathFromBy(selecteur) + "')");
    }
    assertTrue(isElementPresent(selecteur.getChemin()));
}
[...]

Dans les objets Page

A cette étape, il reste maintenant à transformer les sélecteurs « By » qui se trouvent dans vos objets pages. Et en premier paramètre, à vous de jouer : vous devez décrire, du mieux que vous pouvez, ce qu’est l’objet d’un point de vue fonctionnel ; à quoi il sert. Vous devez être concis, mais surtout précis, pour éviter toute ambiguïté.

private final Selecteur BTN_CLASSER_PAR_PRIX = new Selecteur("le bouton permettant de classer les articles par prix", By.xpath("(//a[contains(@href, 'orderBy=prix')])[1]"));

Résultats de la refacto

Une fois que c’est fait, on reteste pour voir à quoi ressemblent maintenant les logs !

Accès à l'URL https://automobiles.nc/
Renseignement du texte '107' dans le champ de recherche
Clic sur le bouton permettant de valider la recherche
Clic sur le lien vers les offres
Clic sur le bouton permettant de classer les articles par prix
Clic sur le bouton permettant de déplier l'annonce n°1
ERREUR : le prix affiché est supérieur à 10000

Là, on a toutes les informations et on comprend tout. Et que se passe-t-il si on regarde, comme au début de l’article, ce que montrent les logs si jamais le champ de recherche a disparu ?

Accès à l'URL https://automobiles.nc/
Renseignement du texte '107' dans le champ de recherche
ERREUR : le champ de recherche n'a pas été trouvé(e) sur la page. (sélecteur : 'recherche')

Bien, on comprend aussi.

[BONUS] Le script Selenium niveau serial-bugkiller : le générateur de rapport de bug

Tels quels, vos logs expliqueront ce qu’on fait les automates de test. En changeant peu de choses à la proposition précédente, vos logs détailleront les étapes à suivre pour reproduire leur comportement. Et du coup, vous mettrez un peu moins de temps à rédiger vos rapports de bugs, car votre partie « Etapes pour reproduire » sera déjà écrite par votre automate, et n’importe qui pourra la comprendre, quel que soit son niveau de connaissance du projet.

Rendez-vous sur l'URL https://automobiles.nc/
Renseigner le texte '107' dans le champ de recherche
Cliquer sur le bouton permettant de valider la recherche
Cliquer sur le lien vers les offres
Cliquer sur le bouton permettant de classer les articles par prix
Cliquer sur le bouton permettant de déplier l'annonce n°1
ERREUR : le prix affiché est supérieur à 10000

Vous n’aurez peut-être pas besoin de ce type de logs, ceux de l’étape précédente vous suffiront peut-être, mais cela vous donnera peut-être d’autres idées d’utilisations des logs.

Conclusion

En conclusion, nous pourrions dire qu’il est illusoire de rechercher une Peugeot 107 à 10 000 XPF ou moins.

Mais aussi, que vos logs sont un atout dont vous pouvez tirer une grande valeur, et à peu de frais. Ce que nous avons exploré dans cet article n’est qu’un exemple parmi d’autres de valorisation des logs.

Et vous, comment utilisez-vous vos logs de tests automatisés ? Comment les avez-vous améliorés au fil du temps ?

Crédit image

L’image de couverture est une reprise de Miss Auras (Le Livre rouge), Sir John Lavery (1856-1941).

SonarQube met son grain de sel dans Gitlab !

La galaxie SonarQube

Dans de précédents articles, nous avons présenté SonarQube, son interface ainsi que son intégration avec Jenkins, et SonarLint, son acolyte qui permet aux développeurs de vérifier la qualité de leur code avant de le commiter. Aujourd’hui, nous voulons affiner encore les choses, et différencier l’analyse des branches features et master.

Cet article présente un applicatif open-source, disponible en l’état et sans garantie. Il est de la responsabilité du SI de vérifier qu’il est conforme à sa politique de sécurité d’une part, et de respecter sa licence d’autre part. Merci à Gabriel Allaigre, de Talanlabs, pour le plugin Sonar-Gitlab !

La procédure suivante met en oeuvre SonarQube, Gitlab et Jenkins en environnement Linux.

Problème initial : trop ou trop peu de données qualimétriques ?

Entre surcharge informationnelle…

Dans un projet donné, il arrive que chaque branche (de feature ou même de bug) fasse l’objet d’une analyse SonarQube à chaque fois que du nouveau code est poussé dessus. Les résultats de cette analyse sont alors stockés dans la base de données et affichés dans l’interface.

Le problème, c’est qu’il en résulte rapidement une liste interminable de « projets » SonarQube qui n’en sont pas ; ce ne sont que des branches ! Ces résultats sont conservés indéfiniment alors qu’ils perdent leur intérêt dès que les branches sont fusionnées.

Comment éviter ce bruit tout en conservant le feedback de SonarQube ?

… et isolement des informations

Par ailleurs, il est assez courant d’entendre des témoignages de ce type : « Nous avons installé SonarQube et des analyses sont régulièrement lancées sur nos projets, mais en pratique on ne les regarde pas souvent. » Effectivement : SonarQube est simple à installer, simple à configurer et simple à utiliser. Le plus difficile est de l’intégrer pleinement aux modes de travail des équipes.

Le plugin présenté ici vise à résoudre le premier problème, tout en apportant un élément de solution au second.

Comprendre les lancements d’analyse SonarQube

Il faut d’abord savoir que SonarQube dispose de 3 modes de lancement :

  • Analysis : il s’agit du mode de lancement par défaut de SonarQube. Tous les fichiers sont analysés et SonarQube crée ou met à jour un projet dans sa base de données.
  • Preview : tous les fichiers sont également analysés mais les résultats ne sont pas stockée dans la base de données.
  • Incremental : seul le fichier courant ou les derniers fichiers modifiés sont analysés. Il s’agit du mode de lancement par défaut de SonarLint.
    Source : https://blog.sonarsource.com/analysis-vs-preview-vs-incremental-preview-in-sonarqube/

Ce sont sur ces modes de lancement que nous allons nous appuyer pour différencier les analyses des branches features et master :

  • Pour la branche master, nous allons continuer d’utiliser le mode analysis, et stocker les résultats dans la base de données.
  • Pour les branches temporaires, nous allons basculer sur le mode preview, ce qui va nous permettre de générer le rapport et de le visionner… sur Gitlab !

L’idée est de permettre à un utilisateur Gitlab dédié (que l’on nommera tout simplement SonarQube) de commenter les commits en indiquant les mauvaises pratiques détectées dans les portions de nouveau code.

Mise en pratique

Récupération du plugin

La dernière version stable du plugin Sonar-Gitlab est disponible depuis le centre de mise à jour de SonarQube, vous pouvez l’y installer directement.

Si vous souhaitez utiliser la toute dernière version du plugin, vous devrez récupérer le projet Sonar Gitlab Plugin sur la page Github du projet, placer le jar dans le répertoire « plugins » de Sonarqube (SONARQUBE_HOME/extensions/plugins) puis redémarrer SonarQube.

Configuration de Gitlab

  1. Créer un compte Gitlab avec comme nom SonarQube
  2. Se connecter sur Gitlab en tant qu’administrateur et attribuer à l’utilisateur SonarQube le profil « Développeur » dans les groupes contenant les projets à analyser
  3. Se connecter sur Gitlab avec l’utilisateur SonarQube et générer un token sur la page http://urldegitlab/profile/personal_access_tokens

Configuration de SonarQube

  1. Se connecter sur SonarQube en tant qu’administrateur
  2. Dans « Configuration », se rendre dans le tout nouvel onglet « Gitlab »
  3. Dans le formulaire qui s’ouvre, renseigner le token
  4. Remplir les champs « Global template » et « Inline template » en adaptant les templates proposés ici : https://gitlab.talanlabs.com/gabriel-allaigre/sonar-gitlab-plugin#examples

Configuration du projet à analyser

  1. Sur Gitlab, récupérer l’id du projet souhaité, qui se trouve dans les Settings du projet.
  2. Sur SonarQube, revenir à l’écran des projets, cliquer sur le projet concerné, puis sur « Configuration » > « Paramètres projet » > « Gitlab »
  3. Dans le formulaire qui s’affiche, renseigner l’id du projet récupéré dans Gitlab et, éventuellement, adapter les barrières qualité du projet
  4. Pour être analysé par SonarQube, un projet doit contenir un fichier sonar-project.properties. Ajouter les deux lignes suivantes à ce fichier :
     sonar.analysis.mode=${MODE_ANALYSE}
     ${GITLAB_CONFIG}

    A noter : les variables ${MODE_ANALYSE} et ${GITLAB_CONFIG} seront remplacées au moment du build Jenkins.

Configuration du job Jenkins

  1. Sur Jenkins, créer un build et ajuster les actions déclenchant le build ; ici, à chaque fois qu’un changement a lieu sur Gitlab
  2. Lors de l’étape de récupération des sources, prendre soin de ne cibler aucune branche en particulier.
  3. Ajouter une étape « Exécuter un script shell » avec le script suivant :
     ID_PROJET="124" # id du projet, à récupérer dans Gitlab
     URL_SONARQUBE="http://urldesonarqube"
     SHA_DERNIER_COMMIT=$GIT_COMMIT
     if ["$GIT_BRANCH" = "origin/master" ];
    then
     echo "Nous sommes sur la branche master. Les résultats de cette analyse seront enregistrés dans la base de données de SonarQube."
     sed -i "s/${MODE_ANALYSE}/publish/g" sonar-project.properties # on suppose que ce fichier est à la racine du projet. Adapter le chemin si besoin.
     sed -i "s/${GITLAB_CONFIG}//g" sonar-project.properties
     else
     echo "Nous sommes sur une autre branche que master. Les résultats de cette analyse seront enregistrés dans les commentaires de l'utilisateur SonarQube dans Gitlab."
     sed -i "s/${MODE_ANALYSE}/preview/g" sonar-project.properties
     # Configuration Gitlab
     sed -i "s/${GITLAB_CONFIG}/sonar.gitlab.commit_sha=${CI_BUILD_REF}nsonar.gitlab.ref_name=${CI_BUILD_REF_NAME}nsonar.gitlab.project_id=${ID_PROJET}nsonar.host.url=${URL_SONARQUBE}nsonar.issuesReport.console.enable=true/g" sonar-project.properties
     sed -i "s/${CI_BUILD_REF}/$SHA_DERNIER_COMMIT/g" sonar-project.properties
     sed -i "s/${CI_BUILD_REF_NAME}/$SHA_DERNIER_COMMIT/g" sonar-project.properties
     fi
  4. Ajouter l’étape de lancement de l’analyse SonarQube.

Intégrer l’analyse de code à tous les niveaux

Récapitulons. Désormais, à chaque changement dans le dépôt Gitlab, un build Jenkins sera lancé. Si c’est la branche master qui est concernée, un rapport sera enregistré dans la base de données de SonarQube ; sinon, des commentaires seront postés sur le commit pour indiquer d’éventuelles mauvaises pratiques dans le nouveau code introduit.

Bonnes analyses !

Vous aimerez peut-être…

Sondez votre code avec SonarQube

La qualité de code en direct avec SonarLint !

5 graphiques Jira pour mieux communiquer sur les anomalies

Avertissement : cet article contient des liens d’images temporairement inactifs. Nos excuses pour ce dérangement !

Avoir les bonnes métriques au bon moment

« Combien a-t-on d’anomalies ouvertes ? »

Voilà une question que les testeurs entendent souvent, mais qui n’amène qu’une réponse assez sommaire.

Le produit comptabilise 200 anomalies ouvertes ? Simplement en tenant compte de la criticité des bugs, on découvrira peut-être qu’il est de meilleure qualité qu’il y a quelques mois, où il n’en comptait que 150.

Un backlog d’anomalies en dit long sur son projet. En prenant le temps de l’analyser, on peut être en mesure de répondre aux questions suivantes :

  • Où se regroupent les défauts ?
  • Comment la qualité du produit évolue-t-elle dans le temps ?
  • Le nombre de régressions augmente-t-il ou diminue-t-il ?

Autant d’informations qui permettent de détecter aussi bien des risques projet que des risques produit.

Dans votre organisation, si la gestion des anomalies se fait sur Jira, cet outil vous sera d’une grande aide pour analyser et communiquer autour des anomalies de vos projets. Il permet de créer un certain nombre de graphiques, appelés « gadgets ». En voici quelques mises en pratique !

Prérequis : savoir comment gérer les filtres Jira

Les filtres constituent une fonctionnalité phare de Jira. Ils permettent aussi bien de retrouver rapidement un lot de demandes que de créer des graphiques à partir de celles-ci.

Après avoir effectué une recherche à plusieurs critères, il suffit d’enregistrer celle-ci en lui donnant un nom. Votre filtre est prêt à être utilisé. Pour cela, rendez-vous dans l’onglet « Tableaux de bord » et cliquez sur « Ajouter un gadget ».

Comptabiliser une dimension des anomalies avec le graphique « Statistiques de demandes »

Priorité des bugs

Le graphique « Statistiques de demandes », très simple, permet de visualiser une facette donnée d’un lot de demandes. Ici, nous avons choisi la priorité des bugs. Ce qui nuance, comme dit précédemment, le simple nombre de bugs.

Pour rappel, le lot d’anomalies est défini par le filtre choisi. Il peut être intéressant de comparer un graphique portant sur toutes les anomalies d’un projet, à un graphique portant uniquement sur les anomalies ouvertes de ce projet.

NB : Jira, contrairement à Bugzilla ou Mantis, ne comporte pas de champ « Sévérité » ou « Impact ». C’est un reproche que l’on peut faire à la plateforme, car en pratique un bug de sévérité mineure peut être prioritaire par rapport à un bug de sévérité majeure. En revanche, il est possible de contourner cette limitation en créant un champ personnalisé.

Statut des bugs

Voici ci-dessus un autre exemple d’application du graphique « Statistiques de demandes », portant cette fois sur l’état des demandes. Un nombre élevé d’anomalies rouvertes peut indiquer une fréquence importante de régressions, ou une attention insuffisante portées aux corrections. Un graphique a toujours besoin d’une interprétation ; le testeur est aussi là pour ça.

Identifier les zones à risque de l’application avec le graphique « Carte thermique »

Créer un nuage de bugs

L’un des 7 principes généraux du test énoncés par l’ISTQB met en valeur la tendance des bugs à se regrouper. Par expérience, un testeur affecté depuis quelques temps à un projet donné saura où focaliser son effort de test, en particulier lors de ses tests exploratoires. Mais cela ne suffit pas : il faut aussi pouvoir mettre en évidence auprès de toutes les parties prenantes les zones sensibles de l’application, afin qu’elles y accordent une attention particulière.

Sur Jira, le gadget « Carte thermique » génère un nuage de mots qui affiche chacun d’eux avec une police proportionnelle à son nombre d’occurrences. Ces mots peuvent être issus d’une multitudes de critères. Dans un projet donné, chaque anomalie peut se voir attribuer une ou plusieurs étiquettes correspondant aux blocs fonctionnels concernés. La carte thermique portant sur les étiquettes permettra alors d’identifier les fonctionnalités les plus sensibles, comme ci-dessous.

Avantages de ce graphique

Cette vision peut aider à organiser la correction d’anomalies en mettant entre parenthèses le seul critère de priorité. Cela présente plusieurs avantages. Quand une personne se charge d’un lot d’anomalies concentrées sur une même fonctionnalité :

  • Elle termine généralement le travail plus rapidement que si plusieurs personnes s’y étaient attelé les unes après les autres
  • Comme elle se plonge dans la fonctionnalité dans son ensemble, elle monte en compétence sur l’ensemble de ses aspects, ce qui pourra l’aider à la faire évoluer par la suite
  • A l’issue de cette correction, le client peut se sentir soulagé de constater que pour une fonctionnalité, tout fonctionne correctement
  • Des anomalies mineures ou triviales, qui auraient été ignorées sinon, peuvent être épongées.

Evaluer la dette technique avec le graphique « Demandes créées comparées aux demandes résolues »

Comme dit précédemment, le nombre d’anomalies ouvertes peut s’interpréter de différentes façons. Il est aussi intéressant d’analyser le graphique comparant le nombre de demandes créées au nombre de demandes résolues, pour adapter si besoin l’effort de correction d’anomalies. Un gadget dédié est disponible sur Jira.

Très parlant, il permet de voir en un coup d’oeil si la dette technique est en train de se résorber ou au contraire de s’accentuer.

Identifier les moments critiques avec le graphique « Plage de demandes »

« Cette appli est de plus en plus bugguée ! »

Le graphique « Plage de demandes » permet de communiquer sur le nombre d’ouvertures de bugs au fil du temps. Prenez le temps de bien expliciter les différentes hausses et baisses, qui peuvent être dues à des facteurs très différents (nouvel interfaçage avec un autre système complexe, congés d’une partie de l’équipe, livraison de nouvelles fonctionnalités, phase soutenue de correction d’anomalies, arrivée de nouveaux testeurs, refacto…)

Pensez à désactiver l’option « cumulative ». Sans cela, le graphique afficherait une courbe croissante, qui ne permettrait pas aussi bien d’identifier les pics de bugs.

Evaluer le turn-over des bugs avec le graphique « Âge moyen »

Assez difficile à interpréter, ce graphique peut toutefois fournir des chiffres « choc » pour motiver la correction d’anomalies.

Un bémol cependant : ces chiffres sont de moins en moins parlants au fil du temps, car dans l’ensemble, il est normal que les bugs bloquants récents soient corrigés avant les bugs triviaux anciens.

Il peut être intéressant d’ajouter la notion de criticité à ce filtre.

Partager les graphiques

Il est important que les parties prenantes puissent accéder aux graphiques à volonté. Cela permettra à tout un chacun de prendre quand il le souhaite la température du projet. Pour cela, plusieurs solutions :

  • Insérer ces graphiques dans un ou plusieurs tableaux de bord partagés (sur Jira)
  • Profiter de l’intégration Jira-Confluence pour intégrer les gadgets sur une page de wiki, ce qui permettra de commenter au fur et à mesure l’évolution des données affichées

  • Périodiquement, envoyer des rapports (par mail ou autre) intégrant des copies d’écran de ces graphiques, avec un lien pour accéder à leur version dynamique.

Nous espérons vous avoir donné des idées, n’hésitez pas à partager vos propres graphiques avec nous !

Vous aimerez peut-être…

Réunion de clôture : un jeu pour finir en beauté !

Testeur en contexte Agile

La qualité de code en direct avec SonarLint !

A quoi sert SonarLint ?

Après notre présentation de SonarQube, nous vous proposons maintenant de prendre le problème de la qualité de code à la racine avec SonarLint.

En effet, SonarLint est un plugin permettant de réaliser les analyse de code SonarQube au fil des développements, directement dans l’IDE. Un bon coup de pouce pour identifier au plus tôt, c’est-à-dire avant même le commit, les points à corriger. De ce fait, le coût de la qualité du code est extrêmement réduit, voire invisible, à l’inverse des lourdes campagnes correctives qui interviennent sur du code déjà mergé depuis longtemps.

Ici, un exemple avec Intellij. Il est à noter que ce plugin est également dispo pour Eclipse et Visual Studio.

Installation du plugin SonarLint sur Intellij

  • Ouvrir Intellij
  • Aller dans « File » > « Settings » > « Plugins »
  • Cliquer sur « Browse repositories »
  • Rechercher « SonarLint », l’installer et redémarrer Intellij

Lancer une analyse SonarLint

Pour lancer une analyse, cliquez sur l’onglet « Analyze » d’Intellij. Vous verrez les options SonarLint dans une liste déroulante.

Si par exemple nous lançons une analyse sur tous les fichiers (attention, cette opération peut s’avérer assez longue sur les gros projets), nous obtenons une vue telle que celle-ci :

Un double-clic sur une anomalie permet d’accéder à la ligne de code en question, ainsi qu’à l’explication du problème afin de pouvoir le corriger en connaissance de cause.

Intégration de SonarLint avec un serveur SonarQube

Partagez vos règles SonarQube sur tous les postes

Très bien, nous pouvons maintenant voir très rapidement les défauts de notre code dans la console SonarLint. Mais ce qui serait encore mieux, ce serait de partager les mêmes règles que le reste de l’équipe, à savoir les règles définies dans le serveur SonarQube central. Ces règles correspondent au(x) profil(s) qualité utilisé(s) pour le projet.

Pour ce faire :

  • Aller dans « File » > « Settings » > « Other settings » > « SonarLint General Settings ».
  • Ajouter un serveur SonarQube. Pour ce faire, il y a besoin d’un token (souvenez-vous, nous en avions besoin aussi pour interfacer SonarQube avec Jenkins !), ou d’un couple login/password.
  • Dans l’onglet « SonarLint Project Settings », associer le projet courant au projet correspondant dans SonarQube. Il est important que le nom du projet soit le même dans les deux outils.
  • De retour dans l’onglet « SonarLint General Settings », cliquer sur le bouton « Update binding ».

Désormais, vous partagez dans votre IDE le même profil qualité que votre projet SonarQube. Faites un test : introduisez un bug dans votre code, changez la priorité de ce bug dans SonarQube, cliquez de nouveau sur le bouton « Update binding » dans les Settings d’Intellij, et vous verrez que la priorité du bug changera également dans votre IDE lors de la prochaine analyse. Si ce n’est pas le cas, c’est que vous avez manqué une étape !

Résolution de version

Au moment de la mise à jour du lien SonarQube – SonarLint, une popup d’erreur peut survenir, avec un message comme celui-ci :

The following plugins do not meet the required minimum versions, please upgrade them: *** (installed: x.x, minimum: x.x).

Il s’agit la plupart du temps d’un package de règles d’un langage qui doit être mis à jour dans SonarQube. Pour régler ce problème de version :

  • Se rendre sur l’interface SonarQube
  • Se connecter avec un compte administrateur
  • Aller dans « Configuration » > « Système » > « Mises à jour »
  • Mettre à jour le module mentionné dans le message d’erreur.

Conclusion

Le plugin SonarLint représente une opportunité pour les développeurs, car il aide à renforcer la qualité de code au fur et à mesure de l’écriture. Moins de risque d’oublis donc, et un allègement significatif des retours produits lors de la revue de code.

Un point d’alerte toutefois : il faut veiller à ce que les règles définies dans le profil qualité soient pertinentes, c’est-à-dire adaptées à la fois au projet et à l’équipe concernée. Sans cela, une part plus ou moins importante des analyses produites par SonarLint sera tout simplement ignorée par les équipes de développement.

Vous aimerez peut-être…

Sondez votre code avec SonarQube

SonarQube met son grain de sel dans Gitlab !