Auteur/autrice : admin@hightest

Note préalable : cet article date de 2017. Depuis, Protractor a atteint la fin de sa vie. Merci à lui et surtout aux personnes qui ont contribué à cet outil !

Diviser pour mieux tester

Bienvenue dans la 3ème et dernière partie de notre série d’articles sur la découverte des tests Protractor ! Dans l’article précédent, nous avons vu pourquoi et comment séparer les jeux de données et les scripts de test. Aujourd’hui, nous poursuivons sur notre lancée en isolant la description des pages et en structurant les dossier du projet.

1. Installation et exemple de script
2. Gestion des jeux de données et des dépendances du projet
3. Structure d’un projet industrialisé

Gestion du référentiel d’objets avec le Page Object Model

Qu’est-ce que le Page Object Model ?

Le Page Object Model est un design pattern (ou patron de conception) qui consiste à regrouper en une même classe les identificateurs des composants web avec lesquels on souhaite intéragir, ainsi que les méthodes associées à ces composants. Le Page Object Model joue le même rôle dans les projets Selenium que l’Object Repository dans les projets UFT ou Katalon par exemple.

Dans les articles précédent, nous interagissons avec la page d’accueil du site d’Angular. Si nous nous servons d’un objet page pour la décrire, cela donne :

var SiteAngularPageAccueil = function() {
    this.champ_nom = element(by.model('yourName'));
    this.message_salutations = element(by.xpath("//div[contains(@class, 'well')]//h1"));

    this.entrerPrenom = function(prenom) {
        this.champ_nom.sendKeys(prenom);
    };
};

module.exports = SiteAngularPageAccueil;

La méthode entrerPrenom est vraiment simpliste ; en pratique, on pourrait s’en passer. Nous avons choisi de la créer simplement pour fournir un exemple d’utilisation de méthode d’objet.

Enregistrons ce code dans un fichier site-angular-page-accueil.js, que nous plaçons dans un dossier « pages ».

Utilisation de l’objet page dans le script

Mettons à présent à jour le cas de test en appelant l’objet page et en interagissant avec elle :

var donnees = require('./jeu-de-donnees-demo.js');
var using = require('jasmine-data-provider');
var SiteAngularPageAccueil = require('../pages/site-angular-page-accueil.js');

describe("Suite de test de la feature qui dit bonjour", function() {

    var pageAccueil = new SiteAngularPageAccueil();

    beforeEach(function () {
        browser.get(browser.baseUrl);
    });

    using(donnees.prenoms, function (data, description) {
        it("Chaîne de type " + description, function () {
            testMessageSalutations(data.prenom);
        });
    });

    using(donnees.faux_positif, function (data, description) {
        it("Si je rêvasse en écrivant mon script de test, j'obtiens un faux positif", function () {
            testMessageSalutations(data.prenomSaisi, data.prenomVoulu);
        });
    });

    function testMessageSalutations(prenomSaisi, prenomVoulu){
        pageAccueil.entrerPrenom(prenomSaisi);
        var prenomAVerifier = (prenomVoulu ? prenomVoulu : prenomSaisi);
        expect(pageAccueil.message_salutations.getText()).toEqual('Hello ' + prenomAVerifier + '!');
    }

});

Nous avons également créé une fonction testMessageSalutations pour éviter au maximum la duplication entre les deux cas de test.

Le script est maintenant concis et exempt de toute redite ! A ce stade, notre script de test a atteint un niveau de maintenabilité satisfaisant. Il peut jouer une multitude de cas de test différents, et n’est plus soumis aux changements de l’interface du site web.

Exemple de structure de projet Protractor

Pour augmenter la lisibilité de votre projet, nous vous suggérons de ranger dans des répertoires séparés vos fichiers de configuration, vos pages, vos suites de tests et vos jeux de données.

Le nombre de suites de test augmentant, n’hésitez pas à créer des sous-dossiers. Dans vos fichiers de configuration, il sera d’autant plus simple de sélectionner tel ou tel ensemble de suites de tests. Par exemple :

exports.config = {
  seleniumAddress: 'http://localhost:4444/wd/hub',
  specs: ['../specs/front-office/*.js'],
    baseUrl: 'https://www.monsupersiteweb.nc',
    framework: 'jasmine2'
};

Ici, toutes les suites de test se trouvant dans /spec/front-office seront jouées.

Vous avez maintenant tout ce qu’il vous faut pour démarrer votre projet de tests Protractor sur de bonnes bases. A vous de jouer maintenant ! Et vous souhaitez rester encore un peu avec nous, voici un petit bonus…

Bonus : le reporting Jasmine

Vous aurez beau écrire le plus beau code du monde, il y a peu de chances que celui-ci suffise à émouvoir aux larmes votre chef de projet, client ou patron. Un reporting clair et documenté est indispensable pour communiquer sur l’exécution des tests. C’est pourquoi nous ne voulions pas vous quitter avant d’évoquer la librairie Jasmine2 Screenshot Reporter.

Ajout de la librairie

Dans votre package.json, déclarez la dépendance voulue :

"dependencies": {
  // [...]
  "protractor-jasmine2-screenshot-reporter": "0.3.5"
}

Mise à jour du fichier de configuration

Il est maintenant nécessaire d’appeler la librairie dans le fichier de configuration :

var HtmlScreenshotReporter = require('protractor-jasmine2-screenshot-reporter');

var reporter = new HtmlScreenshotReporter({
    dest: '../reports',
    filename: 'reporting-' + getDate(true) + '.html',
    reportOnlyFailedSpecs: false,
    captureOnlyFailedSpecs: true,
    showQuickLinks: true,
    reportTitle: "Rapport de tests automatisés du " + getDate() + "",
    reportFailedUrl: true,
    pathBuilder: function(currentSpec, suites, browserCapabilities) {
        return currentSpec.fullName + "--" + browserCapabilities.get('browserName');
    }
});

exports.config = {
  seleniumAddress: 'http://localhost:4444/wd/hub',
  specs: ['../specs/dis-bonjour.js'],
    baseUrl: 'https://angularjs.org',
    framework: 'jasmine2',

    beforeLaunch: function() {
        return new Promise(function(resolve){
            reporter.beforeLaunch(resolve);
        });
    },

    onPrepare: function() {
        jasmine.getEnv().addReporter(reporter);
    },

    afterLaunch: function(exitCode) {
        return new Promise(function(resolve){
            reporter.afterLaunch(resolve.bind(this, exitCode));
        });
    }
};

function getDate(dansNomFichier) {
    var today = new Date();
    var dd = today.getDate();
    var mm = today.getMonth() + 1;
    var yy = today.getFullYear();
    var hh = today.getHours();
    var min = today.getMinutes();

    if(dd<10) dd='0' + dd;
    if(mm<10) mm='0' + mm;
    if(hh<10) hh='0' + hh;
    if(min<10) min='0' + min;

    if(dansNomFichier){
        today = yy + '-' + mm + '-' + dd + '--' + hh + 'h' + min;
    } else {
        today = yy + '/' + mm + '/' + dd + ', ' + hh + ':' + min;
    }
    return today;
}

Explication du fichier de configuration

dest: '../reports'

Avec cette configuration de la variable dest, si votre fichier de configuration se trouve bien dans un sous-dossier dédié (/src/confs par exemple), un sous-dossier « reports » sera créé dans le dossier « src ». A l’intérieur de ce dossier seront créés les reportings au format html, ainsi que les screenshots.

A chaque lancement, son contenu sera supprimé. Si vous souhaitez conserver les résultats des tests d’un lancement à l’autre, mettez à true la variable preserveDirectory lors de l’instanciation de votre HtmlScreenshotReporter :

preserveDirectory: true,

Dans ce cas, un sous-dossier avec un nom aléatoire sera créé à l’intérieur du dossier « reports ».

filename: 'reporting-' + getDate(true) + '.html',

La variable filename, sans surprise, définit le titre du fichier de reporting ; ici, nous avons choisi de lui ajouter la date et l’heure (voir la fonction « getDate » en bas du fichier).

reportOnlyFailedSpecs: false,
captureOnlyFailedSpecs: true,

Les variables reportOnlyFailedSpecs et captureOnlyFailedSpecs permettent de consigner tous les cas de tests dans le reporting, mais de ne prendre un screenshot qu’en cas d’échec.

showQuickLinks: true,

La variable showQuickLinks est à false par défaut. Ici, elle permet de générer au début du fichier des liens vers chacun des cas de test en échec. Pratique quand on se retrouve avec une très grande campagne de test.

reportTitle: "Rapport de tests automatisés du " + getDate() + "",

La variable reportTitle configure le titre qui s’affiche en haut du rapport html.

reportFailedUrl: true,

La variable reportFailedUrl permet d’afficher dans le reporting l’URL sur laquelle l’échec a eu lieu.

pathBuilder: function(currentSpec, suites, browserCapabilities) {
    return currentSpec.fullName + "--" + browserCapabilities.get('browserName');
}

La fonction pathBuilder permet de définir le nom des fichiers de screenshot. Ici, le nom est composé du titre du cas de test et du nom du navigateur.

Notre série sur Protractor est maintenant terminée. En espérant qu’elle vous aura apporté des éléments, nous sommes curieux d’avoir vos retours sur ce framework.

Pour en savoir plus sur les différents outils de tests automatisés ainsi que leurs usages et leurs bonnes pratiques, rendez-vous ici !

Note préalable : cet article date de 2017. Depuis, Protractor a atteint la fin de sa vie. Merci à lui et surtout aux personnes qui ont contribué à cet outil !

Le problème du tas

Au commencement d’un projet de test, surtout si celui est censé n’être qu’un POC ou un tout petit projet, on a tendance à coder les jeux de données en dur dans le script et à télécharger les librairies au fil de l’eau. Trèèès bieeeen… tant que ça ne dure pas ! Car comme écrivait Beckett en 1957 :

Les grains s’ajoutent aux grains, un à un, et un jour, soudain, c’est un tas, un petit tas, l’impossible tas.

Un tas qu’il n’est pas facile à gérer quand on revient sur le projet quelques mois plus tard, ou qu’un collègue doit travailler dessus pendant qu’on est en vacances à Ouvéa.

Aujourd’hui donc, on vous donne des pistes pour gérer les jeux de données et les librairies de votre projet. Cet article est le deuxième de notre série sur les test Protractor :

1. Installation et exemple de script
2. Gestion des jeux de données et des dépendances du projet
3. Structure d’un projet industrialisé

Quels problèmes souhaitons-nous éviter ?

Pour comprendre l’intérêt de ce qui va suivre, penchons-nous sur ce petit texte :

« Vous a-t-on déjà parlé de la Nouvelle Calédonie, un archipel du Pacifique dont la capitale est Nouméa, qui compte quelque 300 000 habitants et dont la devise est le franc pacifique ? Recherchez le taux de change actuel entre le franc pacifique et l’euro. La Nouvelle Calédonie, un archipel du Pacifique dont la capitale est Nouméa, qui compte quelque 300 000 habitants et dont la devise est le franc pacifique, possède un lagon exceptionnel, classé au patrimoine mondial de l’Unesco. Recherchez depuis quand c’est le cas. L’oiseau fétiche de la Nouvelle Calédonie, un archipel du Pacifique dont la capitale est Nouméa, qui compte quelque 300 000 habitants et dont la devise est le franc pacifique, est le cagou, un oiseau à huppe presque incapable de voler. Trouvez d’où lui vient son nom. Il est très agréable de vivre en Nouvelle Calédonie, un archipel du Pacifique dont la capitale est Nouméa, qui compte quelque 300 000 habitants et dont la devise est le franc pacifique, cependant il faut tenir compte du fait que ce coin de paradis se trouve à quelque 16 000 kilomètres de la métropole. Vérifiez que Nouméa et la ville française la plus éloignée de Paris. »

Du point de vue du lecteur, ce texte est totalement redondant et illisible. Vous auriez préféré ne lire chaque information qu’une seule fois, et votre cerveau aurait rattaché chacune de ces données à la variable « Nouvelle Calédonie », qu’il possédait peut-être déjà. Cela vous aurait permis de vous concentrer davantage sur les questions.

Si l’on se place du point de vue de l’auteur, au prochain recensement de la Nouvelle Calédonie, il faudra qu’il remplace chaque occurrence de « 300 000 » par, peut-être, « 320 000 » ou « 350 000 ». Au fil du temps, le texte s’allongeant les mises à jour deviendront de plus en plus fastidieuses.

Ce texte est comme un projet de test mal architecturé, qui en un seul bloc fournit une multitude d’informations souvent répétitives sur le SUT, et sollicite dans la foulée des vérifications.

La bonne pratique

Autant que possible, nous allons donc prendre soin de séparer les moments où :

• on configure les données du test,
• on donne des informations sur le SUT (identificateurs d’objets, descriptions de page),
• on effectue des vérifications (tel élément est présent, tel texte est visible).

Gestion des données de test avec jasmine-data-provider

En automatisation des tests, une bonne pratique consiste à séparer les données du test et les scripts d’exécution. Cela augmente la maintenabilité des tests et permet aussi à tout un chacun de mettre à jour le jeu de données, sans avoir à connaître l’architecture du projet sur le bout des doigts.

Qui plus est, cela permet d’alimenter un même script avec X jeux de données, et d’augmenter la couverture des tests à moindre coût .

Avec Protractor, le plugin jasmine-data-provider par exemple permet d’implémenter cette séparation données/scripts.

Pour l’utiliser dans l’exemple précédent, nous allons suivre trois étapes.

1) Importer jasmine-data-provider

A la racine de votre projet, téléchargez le package jasmine-data-provider :

npm install jasmine-data-provider --save-dev

Un dossier node_modules va se créer à la racine de votre projet et contenir le paquet voulu.

Il existe une autre manière de procéder, que nous verrons plus tard. En attendant, veillez juste à ne pas répertorier le dossier node_modules dans votre outil de versionning. Par exemple, si vous utilisez Git, ajoutez la ligne « node_modules/ » dans votre fichier .gitignore et votre projet restera léger comme une plume.

2) Modifier le fichier de configuration

Ici, il n’y a qu’une ligne à ajouter :

framework: 'jasmine2'

3) Créer un fichier de données

Ce fichier doit être au format .js. Appelons-le jeux-de-donnees-demo.js.

Ici, nous avons 2 séries de jeux de données. La première comprend 5 jeux de données avec chacun 1 paramètre : le prénom. Outre les caractères spéciaux courants dans la langue française, nous voulons savoir si d’autres caractères spéciaux (ici, arabes et chinois) apparaissent correctement, et si les scripts Javascript sont traités comme du simple texte.

La deuxième série, destinée à générer un faux positif,  a 2 paramètres : le prénom saisi et le prénom attendu.

'use strict';

 module.exports = {
    prenoms: {
        'ASCII': { prenom: 'Robert' },
        'Caractères spéciaux français': { prenom: 'Rôbértà' },
        'Caractères spéciaux arabes': { prenom: 'صباح الخير' },
        'Caractères spéciaux chinois': { prenom: '安' },
        'Script': { prenom: "<script type='text/javascript'>alert('Faille 1');</script>"}
    },

    faux_positif: {
        'Fail !': { prenomSaisi: 'Chloé', prenomVoulu: "Zoé" }
    }
}

La mention « use strict » est facultative mais conseillée, car elle garantit que le code est bien formé.

4) Exploiter le fichier de données au sein du script de test Protractor

Nous allons un peu transformer le script de l’article précédent :

var donnees = require('./jeu-de-donnees-demo.js');
var using = require('jasmine-data-provider');

describe("Suite de test de la feature qui dit bonjour", function() {

    beforeEach(function () {
        browser.get(browser.baseUrl);
    });

    using(donnees.prenoms, function (data, description) {
        it("Chaîne de type " + description, function () {
            element(by.model('yourName')).sendKeys(data.prenom);
            var message= element(by.xpath("//div[contains(@class, 'well')]//h1"));
            expect(message.getText()).toEqual('Hello ' + data.prenom + '!');
        });
    });

    using(donnees.faux_positif, function(data, description) {
        it("Si je rêvasse en écrivant mon script de test, j'obtiens un faux positif", function() {
            element(by.model('yourName')).sendKeys(data.prenomSaisi);
            var message= element(by.xpath("//div[contains(@class, 'well')]//h1"));
            expect(message.getText()).toEqual(data.prenomVoulu);
        });
    });
});

Au début du script, on indique que l’on souhaite utiliser jasmine-data-provider, ainsi que le chemin de notre fichier de données.

Pour le premier cas de test, on déclare qu’on va utiliser la série de données intitulée « prenoms », ce qui nous donne accès aux données (« data ») ainsi qu’au nom de chaque jeu de données (« description »). Pour accéder au paramètre « prenom », il suffit d’indiquer « data.prenom ».

Nous avons également choisi de factoriser, entre les deux cas de test, la première étape, à savoir la consultation de l’URL de base du projet :

beforeEach(function () {
    browser.get(browser.baseUrl);
});

Au lancement, la même méthode de test sera lancée autant de fois qu’il y a de jeux de données, avec les paramètres correspondants.

Gestion des données de test avec csv-parse

NB : cette section a été ajoutée en décembre 2020.

Si vous préférez exploiter des fichiers CSV, c’est possible aussi en utilisant le module csv-parse.

Commencez par installer ce module avec la ligne de commande suivante :

npm install csv-parse

Dans cet exemple, nous utiliseront un fichier de jeu de données nommé donnees.csv, et qui contiendra les informations suivantes :

login,password,prenom
admin,M0t2p@sseAdmin,Amira
user,M0t2p@sseUser,Boniface

Nous allons appeler ce jeu de données dans le script suivant, qui vérifie qu’à l’authentification sur un certain site web, on se retrouve sur une page où l’on voit la mention « Bonjour » suivie du prénom de l’utilisateur.

'use strict';
let fs = require('fs'); // fs pour file system. Il n'y a rien besoin d'installer pour utiliser cela.
const parse = require('csv-parse/lib/sync');
let a = fs.readFileSync('donnees.csv');

const testdata = parse(a, {
    columns: true,
    skip_empty_lines: true
})

describe('Suite de tests d'authentification', function () {
    for (let i of testdata) {       
        it('Connexion et affichage de la page d'accueil', async function () {
            browser.get(browser.baseUrl)
            console.log("Saisie du login : " + i.login)
            element(by.id('input-login-username')).sendKeys(i.login)
            console.log("Saisie du mot de passe : " + i.password)
            element(by.id('input-login-password')).sendKeys(i.password)
            element(by.id('button-login-submit')).click()
            console.log("Vérification de l'affichage des salutations")
            var message= element(by.xpath("//div[contains(@class, 'h1')]"))
            expect(message.getText()).toEqual('Bonjour ' + i.prenom)
        });
    }
});

Et voilà !

(Fin de l’EDIT)

Gestion des dépendances avec le package.json

Nous venons de voir comment rapidement ajouter la dernière version de jasmine-data-provider. Mais cette façon de procéder n’est pas la meilleure au sein d’un projet industrialisé, où certaines problématiques se posent :

• Comment alléger le projet de tests Protractor ?
• Comment faire en sorte que tous les membres de l’équipe utilisent la même version de jasmine-data-provider ?

C’est à ce moment qu’intervient le fichier package.json. Ce fichier, que l’on va placer à la racine du projet, contient une liste de tous les packages dont a besoin le projet. Si vous venez de l’univers Maven, cela devrait vous rappeler le pom.xml, ou le build.gradle si vous venez de la constellation Gradle.

Et la bonne nouvelle, c’est que npm propose une façon rapide de générer un fichier package.json ! Pour ce faire, placez-vous à la racine de votre projet, et tapez la commande :

npm init

Une série de questions sur votre projet vous est posée. Des réponses par défaut vous sont proposées. Pour un petit projet tel que nous venons d’en créer, l’opération dure moins d’une minute.

La valeur entrée pour le « main » dans l’utilitaire n’importe pas du tout ici. Vous pourrez la supprimer de votre package.json.

Pour le « test command », entrez la commande suivante :

node_modules/.bin/protractor src/conf-demo.js

A ce stade, le fichier généré ressemble à cela :

{
  "name": "hightest-demo",
  "version": "1.0.0",
  "description": "Un petit projet de démo pour présenter les tests Protractor",
  "dependencies": {
    "jasmine-data-provider": "^2.2.0"
  },
  "devDependencies": {},
  "scripts": {
    "test": "protractor src/conf-demo.js"
  },
  "author": "",
  "license": "ISC"
}

L’utilitaire a automatiquement détecté le package jasmine-data-provider, et l’a donc déclaré dans le package.json. Vous avez remarqué ce petit accent circonflexe juste avant le numéro de version ? Il fait partie de la syntaxe de versionning de npm (que nous vous invitons à découvrir ici) et permet ici de bénéficier des mises à jour non-majeures du paquet.

Cependant, nous vous conseillons autant que possible de fixer les versions de vos projets, afin d’être sûr d’avoir des configurations similaires d’une machine à l’autre.

Vérifions que tout marche bien : supprimons sauvagement le dossier node_modules créé précédemment, et lançons la commande « npm install » à la racine du projet. Et hop, le dossier réapparaît.

De bonnes fondations sont posées, mais il reste encore quelques éléments à prendre en compte pour que le projet soit industrialisable. A demain pour aller encore plus loin avec votre projet de test Protractor !

Découvrez nos autres séries d’articles !

Notre saga du test audiovisuel

Notre série dédiée aux tests de sécurité

Le kit de secours métaphorique du testeur agile

Note préalable : cet article date de 2017. Depuis, Protractor a atteint la fin de sa vie. Merci à lui et surtout aux personnes qui ont contribué à cet outil !

Pourquoi Protractor ?

Protractor est un framework de test dont le but est de faciliter l’automatisation des tests fonctionnels pour les SUT (system under test) développés avec AngularJS. Il se base sur WebdriverJS, l’implémentation Javascript de Selenium, et intègre des solutions telles que Jasmine, qui permet de rédiger des tests en BDD (behavior-driver development), ou encore Cucumber et Mocha.

Protractor reconnaît les concepts AngularJS, tels que les attributs ng-repeater, ng-controller, ng-model… qui sont employés dans le code HTML pour manipuler les composants web.

D’autres frameworks de test sont bien sûr capables d’automatiser les applications AngularJS, mais utiliser Protractor améliore :

• la rapidité d’écriture des tests
• leur maintenabilité (passer par des xpath ou des sélecteurs CSS serait moins robuste)
• leur lisibilité

Inversement, il est possible d’utiliser Protractor pour automatiser les tests d’une application non-AngularJS (voir cet article).

Nous vous proposons donc une série d’articles sur Protractor :

1. Installation et exemple de script (le présent article !)
2. Gestion des jeux de données et des dépendances du projet
3. Structure d’un projet industrialisé

Nous utilisons ici la version 5 de Protractor.

Installation de Protractor

Voici quelques prérequis avant de pouvoir vous lancer dans les tests avec Protractor :

• Avoir NodeJS installé sur sa machine (ce qui permet d’utiliser npm)
• Pour l’installation, lancer les commandes suivantes :

npm install -g protractor
webdriver-manager update

• Pour démarrer le serveur Selenium sur votre machine, démarrer une invite et lancer la commande :

webdriver-manager start

EDIT de décembre 2020 : Si à ce moment-là votre invite de commande vous indique que « java n’est pas reconnu en tant que commande interne ou externe », assurez-vous que votre PATH contient bien le chemin vers le dossier « bin » qui se trouve dans le dossier où est installé Java. Ca peut ressembler à C:Program FilesJavajdk-xx.x.xbin. (Fin de l’EDIT)

Par défaut, le serveur Selenium est lancé sur le port 4444. Vous pouvez changer le port en ajoutant un paramètre à la commande.

webdriver-manager start –seleniumPort 5555

Tant que vous utiliserez Protractor sur votre machine, ne fermez pas cette invite.

Pour vérifier que le serveur est bien lancé, rendez-vous sur http://localhost:4444/wd/hub (en changeant le port si besoin).

Exemple de test Protractor

Au cours de ce test, nous allons interagir avec un composant de la page d’accueil du site d’AngularJS.

Sur cette page, quand l’utilisateur entre une chaîne de caractères dans le champ « Name », la phrase de salutations se met immédiatement à jour. C’est cette fonctionnalité que nous allons tester.

Dans l’inspecteur, on voit que l’attribut « ng-model » du champ de saisi a pour valeur « yourName » ; c’est cet attribut qui va nous servir lors de l’identification de l’objet.

Nous avons maintenant besoin de 2 fichiers : le fichier de configuration, qui permet de lancer le test, et le script de test en lui-même.

Un script de test Protractor

Le fichier de test (appelons-le dis-bonjour.js) a le contenu suivant :

describe("Suite de test de la feature qui dit bonjour", function() {

  it("Test 1 : si je renseigne mon nom, la feature me dit bonjour", function() {
    browser.get(browser.baseUrl);
    element(by.model('yourName')).sendKeys('Zoé');
    var message= element(by.xpath("//div[contains(@class, 'well')]//h1"));
    expect(message.getText()).toEqual('Hello Zoé!');
  });

  it("Test 2 : si je rêvasse en écrivant mon script de test, j'obtiens un faux positif", function() {
    browser.get('https://angularjs.org');
    element(by.model('yourName')).sendKeys('Chloé');
    var message= element(by.xpath("//div[contains(@class, 'well')]//h1"));
    expect(message.getText()).toEqual('Hello Zoé!');
  });

});

EDIT de décembre 2020 : si vous souhaitez lancer vos tests sur une application qui n’est pas une application Angular, il est important d’intégrer la commande suivante à vos scripts, afin qu’elle empêche Protractor d’attendre qu’Angular soit correctement chargé : browser.waitForAngularEnabled(false). (Fin de l’EDIT)

Structure et la syntaxe du script Protractor

Conformément à la syntaxe Jasmine, la suite de test se déroule dans la fonction « describe ». Chaque test est détaillé dans une fonction « it ».

L’URL de base (browser.baseUrl) est définie dans le fichier de configuration. Rien n’empêche bien sûr d’utiliser une autre URL (comme par exemple dans le deuxième test du fichier).

Fichier de configuration Protractor

Et maintenant, le fichier de configuration qui va permettre de lancer ces deux courts tests. Appelons-le conf.js. Celui-ci est minimaliste et ne contient que l’adresse du serveur Selenium, le chemin du script de test, et l’URL du SUT.

exports.config = {
  seleniumAddress: 'http://localhost:4444/wd/hub',
  specs: ['dis-bonjour.js'],
  baseUrl: 'http://monsupersiteweb.nc'
};

Lancer les tests Protractor en ligne de commande

Maintenant, pour lancer les deux tests contenus dans le script, il suffit d’ouvrir une invite de commande, de se positionner dans le dossier contenant les deux fichiers et de lancer la commande :

protractor conf.js

Remarque : il est possible de changer la baseUrl au moment du lancement du test, ce qui donne :

protractor --baseUrl=http://monsupersiteweb.nc conf.js

Ce qui est pratique si l’on souhaite faire tourner les tests sur différents environnements par exemple.

Par défaut, c’est un navigateur Google Chrome qui s’ouvre et exécute les scénarios définis dans le script de test Protractor. Ce qui donne, dans notre cas, le résultat suivant :

Plutôt clair, non ?

Protractor et les IDE

Pour l’écriture des tests, un simple éditeur de texte suffit pour si l’on veut juste tester les commandes de bases et se faire une idée rapide des possibilités du framework. Mais pour industrialiser un projet de tests automatisés, il est bien sûr préférable d’utiliser un IDE. Il existe des plugins Protractor pour IntelliJ et pour Eclipse. Il est à noter que celui d’IntelliJ n’est disponible que si l’on dispose d’une licence commerciale (version Ultimate, et non Community). Il est possible d’essayer gratuitement la version Ultimate pendant 30 jours.

Protractor avec Eclipse

EDIT de décembre 2020 : le bug évoqué est peut-être résolu depuis, nous n’avons pas réessayé. (Fin de l’EDIT)

Configurer le plugin Protractor d’Eclipse nécessite quelques manipulations en plus (détaillées dans cette vidéo). Attention toutefois, en mars 2017 un bug empêchait le plugin de tourner correctement.

En effet, la configuration de Run Protractor utilise par défaut la version 4.2.4 de NodeJS, alors que 2 versions majeures ont été publiées depuis !

Indiquer un chemin vers un exécutable plus récent est possible, mais provoque une erreur : « Error while launching client file, Cannot find node install path node-native ».

A suivre donc… Pour la suite de cette série d’articles, nous utiliserons donc la solution d’évitement : passer sur la version d’essai d’IntelliJ.

Protractor avec IntelliJ

1. Créez un projet.
2. Dans le fichier src, placez vos 2 fichiers (test et configuration).
3. Créer une « Run configuration » Protractor
4. Renseigner le chemin vers le fichier de configuration. Les chemins vers NodeJS et Protractor sont, normalement, trouvée automatiquement.

Voilà ce à quoi ressemblent les résultats d’exécution :

Protractor avec Visual Studio Code

Ce paragraphe est un EDIT de décembre 2020.

Ouvrez une nouvelle fenêtre de Visual Studio code ; dans la partie de droite de l’écran s’affiche un encart appelé « Customize ». Dans la partie « Tools and languages », faites en sorte que VSC supporte JavaScript, TypeScript, et si vous le sentez vous pouvez également installer d’autres extensions telles que Mocha Snippets ou Protractor Snippets, qui proposent des raccourcis permettant d’accélérer la saisie des scripts de test Protractor.

Cette manipulation décuplera votre productivité par l’autocomplétion !

(Fin de l’EDIT)

On se retrouve demain pour aller plus loin dans l’exploration de Protractor. Car on ne veut pas seulement créer un test, on veut pouvoir le jouer avec une multitude de jeux de données !

1. Pourquoi utiliser 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, manque ou surcharge de commentaires…) Très utilisé dans les DSI, il gagne donc à être connu au moins dans ses grandes lignes !

2. Quels défauts SonarQube permet-il d’identifier ?

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

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

3. 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. Il est donc important de déterminer si l’on souhaite tous les corriger, ou si certains peuvent être acceptés (mais nous en reparlerons tout à l’heure !)

4. SonarQube et les tests unitaires, c’est pareil ?

Attention ! Même si les deux se focalisent sur le code, et non sur les interfaces des applications à tester, il ne faut pas confondre les analyses SonarQube et les tests unitaires. Ce n’est pas du tout la même chose. Premièrement, les tests unitaires exécutent des composants de l’application à tester ; ils ne font donc pas partie des outils d’analyse statique. Deuxièmement, les tests unitaires permettent de vérifier des fonctionnements de l’application, alors que les analyses SonarQube s’attachent à la qualité du code, sans savoir ce que ce code est censé faire.

Pour faire un parallèle, les logiciels sont comme des textes dont les tests unitaires vérifient le sens et la cohérence, et dont SonarQube vérifie l’orthographe et la lisibilité. Dans son roman Sodome et Gomorrhe, Marcel Proust a écrit une phrase de 856 mots ; si ce roman était un logiciel, SonarQube aurait sans doute remonté une erreur (mais les tests unitaires seraient passés !)

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

5. Comment 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 :

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

6. Quelles sont les fonctionnalités de SonarQube ?

Rentrons maintenant dans le vif du sujet en faisant le tour des principales fonctionnalités de SonarQube !

Analyse des résultats SonarQube

En supposant que SonarQube soit 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é.

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. C’est donc un véritable outil d’amélioration continue !

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 en effet 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é que SonarQube attribue à chaque défaut. La détection de certains défauts peut aussi être désactivée. Lors des analyses suivantes, ils seront donc ignorés.

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

7. Comment 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.

Comment faire ? C’est simple :

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 prévaudront.

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 :

8. Qu’est-ce qu’il ne faut pas attendre de SonarQube ?

Une exactitude indiscutable

Il est nécessaire de qualifier chaque défaut que SonarQube identifie ; nul logiciel de test automatisé n’est à l’abri d’un faux positif. Pour reprendre la métaphore du roman, qui oserait « refactorer » les romans de Proust sous prétexte qu’il a écrit un certain nombre de trèèèèès longues phrases ?

Il ne faut pas oublier que les problèmes remontés par SonarQube sont issus de scans qui repèrent des motifs présents dans le code. Parfois, ce sont donc ces motifs qu’il faut interroger et remettre en question. Et c’est bien pour ça que SonarQube propose de pouvoir gérer les règles comme bon nous semble !

Un substitut aux revues de code

Les analyses quantitatives de SonarQube peuvent être trompeuses. En effet, ce n’est pas parce que 20% des lignes d’une application sont des commentaires que ceux-ci sont véritablement utiles et apportent de la valeur. De même, ce n’est pas parce que SonarQube n’a pas identifié de duplications 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.

D’ailleurs, si le sujet des revues de code vous intéresse, nous vous conseillons vivement de découvrir l’outil Promyze, plateforme de gestion collaborative de la qualité de code.

Conclusion

SonarQube permet donc 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 !

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

Janvier 2018 : l’éclosion

Mars 2019 : l’explosion

Juin 2020

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

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 !