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.
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 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.
Il n'est pas rare, quand on construit un build Jenkins avec des paramètres, que ceux-ci dépendent les uns des autres.
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".
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.
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.
« 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.
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.
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.
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.
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.