L’auteur propose dans cet article, paru initialement dans le magazine Programmez! #263, de voir comment Robot Framework va permettre d’automatiser un test automatique de niveau “Acceptation” à partir d’un exemple simple mais réaliste.
Introduction
Sur le site du projet Robot Framework nous pouvons lire ceci :
« Robot Framework est un framework d’automatisation générique et open source pour les tests d’acceptation, le développement piloté par les tests d’acceptation (ATDD) et l’automatisation des processus robotiques (RPA). »
En effet, Robot Framework (RFW) a été conçu pour automatiser les tests de niveau « Acceptation » (en anglais: « Acceptance Testing ») ou “Système”. Il permet à ce titre de pratiquer l’Acceptance Test Driven Developpement (ou ATDD, sujet sur lequel nous reviendrons). Cela signifie que son domaine de prédilection est celui de l’utilisateur final du logiciel. RFW va donc permettre d’automatiser les actions que pourrait réaliser l’utilisateur. D’ailleurs, le nom « Robot » porte en lui-même l’idée que l’on cherche à reproduire de façon programmatique le comportement d’un humain.
Attention, cela ne signifie pas que l’on puisse utiliser Robot Framework à d’autres niveaux de test, comme par exemple les tests d’intégration mais il est par exemple peu pertinent de l’utiliser pour des tests unitaires.
Note : les tests automatiques dont on parle ici sont généralement des tests de bout en bout ou end-to-end (E2E). Le logiciel à tester est alors placé dans des conditions réelles d’utilisation.
Partie 1 : Les grands principes
Le “Keyword Driven Testing”
Cette introduction nous conduit à parler de la manière dont nous allons écrire les scripts pour automatiser ces tests d’acceptation, en l’occurrence en utilisant le Keyword Driven Testing* (KDT)
Le KDT est une méthodologie de test qui cherche à faire le lien entre le Test manuel et le Test automatisé. Il consiste à décrire les cas de test sous une forme se rapprochant d’un test manuel, en décrivant les étapes et les résultats attendus.
Les étapes sont constituées de mots-clés (keywords) qui représentent les actions élémentaires de haut-niveau. Ces actions sont généralement compréhensibles par toutes les parties prenantes (non seulement l’équipe de développement mais aussi le client). Lors de l’exécution, ces keywords font appel à du code, des librairies de test. Ces librairies de test permettent d’exécuter concrètement les keywords et de dérouler le test de manière automatique.
Avec RFW, il est également possible de combiner des keywords, ainsi les keywords peuvent eux-mêmes faire appel à d’autres keywords pour créer en quelques sortes des keywords de plus haut-niveau, et ainsi de suite par imbrication successive.
Pour résumer le principe, le KDT va permettre d’écrire des scripts de la même manière que l’on décrirait le comportement d’un utilisateur, ou d’une manière très proche.
On utilise souvent une forme tabulaire pour décrire ces keywords ainsi que leurs paramètres :
| Etape | Keyword | Paramètre |
|---|---|---|
| 1 | Open Browser To Login Page | monsite.com/login |
| 2 | Input Username | monLogin |
| 3 | Input Password | Pa$5w0rD |
| 4 | Submit Credentials | |
| 5 | Welcome Page Should Be Open |
Et l’ATDD dans tout ça ?
Nous avons déjà abordé rapidement ce terme mais nous allons ici l’expliquer plus en détail.
D’abord une petite définition : un Test d’Acceptation (ou d’Acceptance en anglais) est un test décrit du point de vue de l’utilisateur final, visant à valider le bon fonctionnement, en vue de faire accepter la livraison par le client, ou en tous cas les parties prenantes (à commencer par l’équipe en charge du développement).
L’Acceptance Test Driven Developpement (ATDD) est une méthode de développement qui s’appuie sur les tests que l’on réalise au niveau “Acceptation”. L’idée est d’écrire les tests d’acceptation avant même que la fonctionnalité n’existe (ou du moins le plus tôt possible). Le test ainsi écrit va servir de référence tout au long du développement. Le test devient alors le fil conducteur (le “D” de driven) du développement. Lorsque ces tests passent, on sait alors que le produit répond aux exigences demandées.
L’ATDD est, comme le TDD (Test Driven Development), une démarche “inversée”. On va d’abord écrire le test puis ensuite se lancer dans l’implémentation.
Pour résumer cette partie un peu “théorique”, nous dirons que RFW va nous permettre d’écrire des tests automatiques d’acceptation sous forme de keywords (en KDT). Il va alors être possible de pratique l’ATDD afin de “sécuriser” le plus rapidement possible les nouveaux développements en proposant un test facilement exécutable (car automatique) avant même la fin du nouveau développement.
Partie 2 : Robot Framework, le couteau-suisse de l’automatisation
Dans le contexte exposé ci-dessus des tests automatiques d’acceptation, RFW va proposer un cadre permettant de réaliser les éléments suivants :
- retranscrire des actions dans un langage expressif proche du langage “naturel” ;
- séquencer l’exécution des scripts ;
- réaliser des vérifications ;
- visualiser les résultats.
Figure 2 : RFW propose un cadre logiciel qui va permettre de créer des tests de manière guidée et modulaire, sans avoir à se soucier de éléments périphériques nécessaires à l’automatisation (exceptées les librairies de tests spécifiques)
De plus, grâce à un système de “plugin” que nous ne décrirons pas ici, il est possible d’étendre facilement les fonctionnalités de base afin d’adapter vraiment RFW à son besoin particulier.
Un point fort de RFW et qui est une des raisons de son succès est la documentation, en particulier le fameux “User Guide” qui est vraiment une mine d’informations. Il existe aussi une documentation plus technique pour les développeurs.
Le dernier point, et pas le moindre, est que le projet Robot Framework est un projet très actif. Il y a un forum, un Slack, une liste de diffusion, une conférence, un Github sans parler de la Fondation RFW qui organise tout cela. Il n’est pas rare (puisque cela a déjà été mon cas) de voir le développeur principal et auteur initial du projet, Pekka Klärck, intervenir dans des discussions pour aider ou clarifier des choses.
Note : RFW peut également être utilisé dans un autre contexte que le Test automatique comme le RPA (Robot Process Automation).
Figure 3 : RFW propose de base une multitude de fonctionnalités autour de l’automatisation. Il n’est donc pas nécessaire de réinventer la roue en voulant recréer son propre outil. Il existe par ailleurs d’autres frameworks d’automatisation (comme Pytest, Cypress, Appium, etc…)
Installation
Robot Framework est un outil programmé en langage Python. Cela lui permet de profiter du riche écosystème qui s’est développé autour de ce langage ces dernières années.
Il est théoriquement possible d’utiliser n’importe quel package Python dans du code RFW bien que généralement des packages dédiés à RFW soient utilisés. Ceci est uniquement dû à une raison de convenance, afin d’avoir plus de facilités d’utilisation mais ce n’est pas une obligation.
Techniquement, RFW est donc capable d’utiliser en natif n’importe quel code Python. Cet aspect signifie aussi que l’on n’est pas “enfermé” dans l’utilisation de RFW et que les librairies Python développées pour tester peuvent être réutilisées à d’autres fins, voire avec d’autres frameworks d’automatisation. C’est par exemple ce que j’ai réalisé pour certaines entreprises, leur permettant ainsi de proposer aux testeurs “le choix” de l’outil d’automatisation.
Python
Nous ne nous attarderons pas sur l’installation de Python tant internet regorge d’informations à ce sujet, sur tous les systèmes d’exploitation possibles (voir les références en fin d’article).
A noter juste qu’il faudra que la version de Python soit supérieure ou égale à 3.8 pour installer RFW 7.0 qui est la dernière version à ce jour.
Une alternative très souvent utilisée est l’usage du “virtualenv” qui permet d’avoir plusieurs projets Python sur la même machine sans risque d’interférence entre eux.
Pour vérifier que Python est bien installé, ouvrir un shell et taper juste la commande : python --version. La commande doit s’exécuter correctement.
Robot Framework
Maintenant venons-en à l’installation de RFW en lui-même. Il s’agit finalement d’un package Python comme un autre et donc l’installation se fait avec la ligne de commande suivante : pip install robotframework
On peut vérifier que RFW est bien installé avec la commande suivante qui affiche la version : robot --version
A noter que RFW n’a aucune dépendance sinon Python. Il n’a donc besoin d’aucune autre librairie externe, ce qui le rend extrêmement portable. Il est bien sûr possible et même conseillé d’utiliser des librairies externes pour pouvoir étendre son utilisation. C’est ce que nous allons d’ailleurs faire pour réaliser notre exercice.
Librairies spécifiques pour Robot Framework
Les librairies permettent d’étendre les capacités de test de RFW. Il en existe des dizaines pour tester toutes sortes de protocoles et de contextes. De plus, si une librairie Robot Framework n’existe pas, il est toujours possible d’utiliser un package Python “standard” qui répond à votre problème. Si vraiment vous ne trouvez pas votre bonheur et que vous avez des compétences en développement Python (ou Java), vous pouvez même écrire votre propre librairie de test.
Nous allons avoir besoin par exemple de deux librairies spécifiques pour notre exercice :
- Browser est une librairie qui utilise Playwright, un outil identique à Selenium, qui permet de réaliser des actions sur un site web comme le ferait un utilisateur.
Nous conseillons de suivre l’installation décrite sur le site de “Browser”. - ImapLibrary2 est une librairie qui permet de se connecter à une boîte mail avec le protocole IMAP afin de réaliser des opérations de lecture des mails.
L’installation est très simple et se fait avec la commande :pip install robotframework-imaplibrary2
Partie 3 : Illustration de la démarche
Venons-en maintenant à l’exercice que nous proposions en introduction pour illustrer la démarche du test d’acceptation avec RFW.
L’idée est de partir d’un élément de travail “traditionnel” dans la méthodologie Agile, à savoir une User Story (US), et de parcourir les différentes étapes qui vont permettre de réaliser l’automatisation du test d’une nouvelle fonctionnalité décrite dans cette US.
L’exemple utilisé est volontairement “petit” afin que le propos tienne dans un article. Les exemples de code ne sont pas forcément fonctionnels en l’état (nécessitent la modification de certaines variables pour fonctionner) mais ils sont réalistes et illustrent vraisemblablement ce que l’on pourrait trouver dans une entreprise.
C’est parti !
1 : la User Story et les critères d’acceptation
Soit la User Story suivante proposée à l’équipe de développement par le Product Owner :
En tant que nouveau client du site,
Je veux recevoir un mail avec un code promotionnel pour un futur achat,
Afin de faciliter un premier achat sur le site
La première question à se poser est donc de définir comment nous allons tester cette fonctionnalité de bout en bout avec un test automatique.
Une US se doit d’être “testable” pour répondre aux bonnes pratiques de l’acronyme “INVEST*”.
Je propose souvent aux équipes que j’accompagne de définir ensemble les critères d’acceptation, c’est-à-dire les différents critères qui permettront de dire que l’US est bien “finie”.
La définition de ces critères peut se faire pendant la phase de raffinage de l’US mais aussi par une pratique nommée “3 Amigos”, qui consiste à faire discuter ensemble un développeur, un testeur avec le Product Owner afin qu’ils déterminent ensemble les critères.
Imaginons que le critère d’acceptation suivant ait été défini lors d’une session de “3 amigos*” :
Etant donné que je suis un nouvel utilisateur du site
Lorsque je remplis le formulaire d’inscription avec mon adresse
Alors je reçois un email avec le code promotionnel “MOINS50” à cette adresse
Le choix a été fait d’écrire ce critère avec le langage “Gherkin*” qui est une pratique possible pour écrire les critères d’acceptation.
2 : Ecriture du test
L’intérêt d’avoir fait cette démarche, combinée à l’utilisation de RFW, est que l’on va pouvoir directement récupérer ce critère et en faire le test d’acceptation de cette US, quasiment tel quel.
L’écriture du test arrive donc très vite dans le processus car il suffit de “copier-coller” le critère d’acceptation pour en faire un test. On commence à percevoir la mise en place de l’ATDD : les critères d’acceptation et les tests qui en découlent, deviennent le guide du développement.
Voici à quoi ressemble l’écriture en RFW de ce test :
*** Test Cases ***
New User Sign Up To The Site
Given I Am A New User 'Anna' 'Lisa'
When I Fill the Sign Up Form With Mail 'a.lisa@example.bzh'
Then I Should Receive A Mail With The Discount Code 'MOINS50' At 'a.lisa@.example.bzh'
Note : nous avons choisi de “traduire” en anglais le critère d’acceptation afin qu’il n’y ait pas de mélange de langue car RFW est à l’origine en anglais. Sachez cependant que depuis une version relativement récente (6.0 d’octobre 2022), RFW gère la localisation. Il est possible d’écrire en français (ou autre langue) tous les tests, même les mots réservés par le langage RFW.
3 : Implémentation de l’automatisation
Comment fonctionne RFW dans ce cas ?
Il “voit” automatiquement que l’on utilise l’écriture Gherkin et il va donc isoler les mots “Given”, “When” et “Then”, puis il va considérer qu’il existe 3 keywords :
I Am A New User 'Anna' 'Lisa'I Fill The Sign Up Form With Mail 'a.lisa@example.bzh'I Should Receive A Mail With The Discount Code 'MOINS50' At 'a.lisa@example.bzh'
Reste à notre charge maintenant de créer ces keywords et d’implémenter les actions qu’ils doivent réaliser sur le produit, grâce aux librairies de test.
Ecriture du premier keyword
Nous allons maintenant écrire les keywords avec RFW.
Le premier keyword va consister à :
- paramétriser le nom et le prénom afin de pouvoir réutiliser ce keyword pour d’autres personnes ;
- sauvegarder le nom et le prénom dans des variables de test pour les réutiliser dans un autre keyword ultérieurement ;
- lancer un navigateur et ouvrir le site grâce à la librairie Browser.
Voici ce que va donner ce keyword :
*** Keywords ***
I Am A New User '${user_firstname}' '${user_lastname}'
Set Test Variable ${FIRSTNAME} ${user_firstname}
Set Test Variable ${LASTNAME} ${user_lastname}
New Browser chromium
New Page https://demoqa.com/text-box
Ecriture du second keyword
Le second keyword va consister à :
- paramétriser l’email ;
- remplir et soumettre le formulaire d’inscription en utilisant la librairie Browser ;
- fermer le navigateur.
*** Keywords ***
I Fill The Sign Up Form With Mail '${user_mail}'
Fill Text id=userName ${FIRSTNAME} ${LASTNAME}
Fill Text id=userEmail ${user_mail}
Click id=submit
Close Browser
Ecriture du troisième keyword
Le troisième keyword va consister à :
- paramétriser le code promotionnel et l’email ;
- vérifier dans la boite mail que l’on a bien reçu un email, en utilisant la librairie ImapLibrary2 ;
- vérifier que le mail contient le code promotionnel.
I Should Receive A Mail With The Discount Code '${discount_code}' At '${user_mail}'
Open Mailbox host=imap.example.bzh user=${user_mail} password=%{MAIL_PASSWORD}
${latest_mail}= Wait For Email subject=Welcome ${FIRSTNAME} ${LASTNAME}! timeout=300
${parts}= Walk Multipart Email ${latest_mail}
FOR ${i} IN RANGE ${parts}
Walk Multipart Email ${latest_mail}
${mail_content}= Get Email Body ${latest_mail}
${contain_discount_code}= Run Keyword And Return Status
... Should Contain ${mail_content} ${discount_code}
IF ${contain_discount_code} RETURN
END
Fail The mail doesn't contain the discount code "${discount_code}"!
[Teardown] Close Mailbox
4. Exécution
En mettant l’ensemble des extraits de code bout à bout, nous obtenons finalement un test relativement concis grâce à l’utilisation des keywords de librairies de test (Browser et ImapLibrary2).
Les keywords que nous avons nous même développés en utilisant le modèle Gherkin sont suffisamment expressifs pour que l’on comprenne rapidement le test et c’est là tout l’objectif des tests d’acceptation et de la démarche ATDD.
Nous obtenons le test suivant, placé dans le fichier programmez.robot :
*** Settings ***
Documentation Feature: New User Sign Up
Library Browser
Library ImapLibrary2
*** Variables ***
${FIRSTNAME} ${EMPTY}
${LASTNAME} ${EMPTY}
*** Test Cases ***
New User Sign Up To The Site
Given I Am A New User 'Anna' 'Lisa'
When I Fill the Sign Up Form With Mail 'a.lisa@example.bzh'
Then I Should Receive A Mail With The Discount Code 'MOINS50' At 'a.lisa@.example.bzh'
*** Keywords ***
I Am A New User '${user_firstname}' '${user_lastname}'
Set Test Variable ${FIRSTNAME} ${user_firstname}
Set Test Variable ${LASTNAME} ${user_lastname}
New Browser chromium
New Page https://demoqa.com/text-box
I Fill The Sign Up Form With Mail '${user_mail}'
Fill Text id=userName ${FIRSTNAME} ${LASTNAME}
Fill Text id=userEmail ${user_mail}
Click id=submit
Close Browser
I Should Receive A Mail With The Discount Code '${discount_code}' At '${user_mail}'
Open Mailbox host=imap.example.bzh user=${user_mail} password=%{MAIL_PASSWORD}
${latest_mail}= Wait For Email subject=Welcome ${FIRSTNAME} ${LASTNAME}! timeout=300
${parts}= Walk Multipart Email ${latest_mail}
FOR ${i} IN RANGE ${parts}
Walk Multipart Email ${latest_mail}
${mail_content}= Get Email Body ${latest_mail}
${contain_discount_code}= Run Keyword And Return Status
... Should Contain ${mail_content} ${discount_code}
IF ${contain_discount_code} RETURN
END
Fail The mail doesn't contain the discount code "${discount_code}"!
[Teardown] Close Mailbox
Remarque : la simplicité du test, bien réelle ici, est possible par la réutilisation de librairies de test existantes (Browser pour gérer le navigateur et ImapLibrary2 pour gérer le mail). Il faut reconnaître que ce n’est pas toujours le cas et qu’il sera parfois nécessaire de développer ses propres librairies ou adapter un package Python existant afin de tester des domaines moins courants.
Maintenant, il reste à exécuter ce test avec la ligne suivante : robot programmez.robot
A la fin de l’exécution, le résultat est présenté dans un fichier HTML dans lequel sont automatiquement affichés :
- l’état des keywords ;
- leur hiérarchie ;
- la valeur de toutes les variables ;
- les temps d’exécution.
Toutes ces informations seront des informations précieuses lorsque le test échouera et qu’il faudra trouver la raison de l’échec :
Classiquement, ce test ainsi écrit entrera dans un pipeline d’Intégration Continue que l’on passera en continu (par exemple chaque nuit). Il permettra d’assurer les tests de régression du produit.
C’est un sujet qui mériterait un article à part entière…
Conclusion
Au delà du langage Robot Framework en lui-même, nous avons vu comment celui-ci pouvait être mis en œuvre dans un exemple concret de test d’acceptation. Nous avons vu l’importance des keywords (et du KDT) dans ce contexte ainsi que la démarche ATDD. Cette manière de travailler permet au testeur de s’impliquer très tôt dans le développement d’une User Story. Il aura ainsi un rôle constructif dans l’élaboration des fonctionnalités et un impact sur la qualité finale du logiciel pendant sa phase de construction. Perspectives intéressantes et complémentaires au rôle traditionnel de “chasseur de bugs”.
Remerciements
Je remercie chaleureusement Anne-Lise Pallier pour la relecture orthographique de cet article et mes collègues de longue date, Corentin Hache et Lucas Lopes Do Nascimento, pour leurs conseils et leur relecture technique.
Références
- Keyword Driven Testing : https://latavernedutesteur.fr/2017/11/03/kdt-keyword-driven-testing/
- Livre “ATDD by example” : https://www.eyrolles.com/Informatique/Livre/atdd-by-example-a-practical-guide-to-acceptance-test-driven-development-9780321784155/
- Installation de Python : https://docs.robotframework.org/docs/getting_started/testing#install-python
- Installation de virtualenv : https://docs.python.org/3/library/venv.html
- Installation de RFW : https://docs.robotframework.org/docs/getting_started/testing#install-robot-framework-globally
- Installation de Browser : https://robotframework-browser.org/#installation
- Critères INVEST : https://en.wikipedia.org/wiki/INVEST_(mnemonic)
- 3 amigos : https://fr.agilitest.com/cards/3-amigos
- Langage Gherkin : https://en.wikipedia.org/wiki/Cucumber_(software)#Gherkin_language
A propos de l’auteur
Je suis Alexis Pallier. Je travaille dans le domaine du Test et de la Qualité logicielle depuis 20 ans. De formation scientifique en maths, IA et robotique, j’ai été Développeur « embarqué » à mes débuts. Puis, par les circonstances de la vie professionnelle, je suis devenu rapidement Testeur. Aujourd’hui, en tant qu’indépendant, j’accompagne mes clients à la mise en place de stratégies de Test, essentiellement basées sur l’automatisation avec Robot Framework et Python. Vous pouvez me retrouver sur LinkedIn et sur mon site professionnel : petit-robot.bzh
Une réponse
Merci Alexis pour cet article. Très intéressant de pouvoir écrire des tests en utilisant le langage Gherkin pour faciliter la communication entre PO, développeurs et testeurs. L’exemple était très parlant!