Robot Framework : le couteau-suisse de l’automatisation

Pour automatiser des tests, il est nécessaire d’utiliser des outils adaptés. Partir la « fleur au fusil » avec pour seule arme un langage de programmation n’est pas suffisant, au risque de devoir réinventer la roue. Nous allons voir ensemble ici les caractéristiques qui font de Robot Framework un bon candidat pour automatiser nos tests logiciels.

Les auteurs de Robot Framework le définissent lui-même comme :

[…] un framework générique et open-source d’automatisation pour le Test de Validation

Très clairement, et nous le verrons dans la suite de cet article, Robot Framework a été conçu pour automatiser les tests du niveau « Validation » (en anglais: « Acceptance Testing ») et pour faire de l’ATDD (Acceptance Test Driven Development). C’est-à-dire que son domaine de prédilection est le même que celui de l’utilisateur final . Il va permettre d’automatiser les actions que pourraient réaliser l’utilisateur du logiciel que l’on souhaite tester. 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 .

Un outil générique de validation

Robot Framework possède des caractéristiques lui permettant de convenir à différentes situations de Test et en particulier de Test de Validation.

La polyvalence

Les librairies « standard » fournies 3 par Robot Framework permettent de réaliser les multiples actions et vérifications nécessaires que pourrait faire un utilisateur pour tester un logiciel.

Les librairies standard permettent, entre autres de:

• manipuler des données de base comme les chaines de caractères, les listes ou les dictionnaires
• manipuler des fichiers, dont des fichiers XML
• manipuler des processus
• manipuler des dates
• faire des assertions, ou autrement dit, faire des vérifications sur tous ces objets
• prendre des captures d’écran
• utiliser le protocole Telnet

Voici un exemple de test dans lequel nous allons rechercher une chaîne de caractère dans un fichier et vérifier qu’elle est bien présente (part 1). Nous allons ensuite lancer un exécutable et vérifier qu’il s’est réellement bien exécuté :

L’adaptabilité

S’adapter au logiciel à tester

Les librairies « standard » permettent, comme nous l’avons vu, d’écrire des tests basiques. Cependant, cela peut paraître limité pour s’adapter à des contextes de test plus évolués. Robot Framework permet aussi d’utiliser des librairies tierces, codées en Python ou en Java. Ceci ouvre la porte à l’automatisation de nombreux logiciels puisqu’il suffit quasiment 4 qu’une librairie (type harnais de test) existe pour que Robot Framework soit capable de se « brancher » dessus et d’exécuter des tests.

On peut citer surement ce qui est la plus « célèbre » des librairies tierces, Selenium, qui permet d’automatiser les tests d’interface web.

Voici un exemple tiré de la documentation de Selenium. Nous allons ouvrir un navigateur sur le site mon-super-site.com, puis saisir notre login et notre mot de passe et enfin vérifier que nous arrivons bien à la page de « bienvenue ».

S’adapter aux testeurs

Nous avons vu comment Robot Framework pouvait s’adapter au logiciel à tester et au contexte de test. Il faut savoir que Robot Framework peut aussi adapter sa manière d’écrire les tests. En effet, il est possible d’écrire les tests de plusieurs manières différentes, soit en KDT 5 (ce que nous avons vu jusque ici dans les extraits de code) c’est à dire avec des instructions qui « collent » aux actions et vérifications que pourrait faire un utilisateur, soit en utilisant le langage Gherkin, couramment utilisé en BDD (6 7).

Cela signifie que l’on peut d’abord partir sur une démarche ATDD, moins contraignante et évoluer ensuite vers une démarche BDD. Cette liberté de choix est aussi intéressante car un même outil peut convenir à plusieurs « populations » différentes au sein d’une même entreprise (Développeur, Testeur, Métier…).

L’évolutivité

Enfin, je voulais parler d’un aspect, qui je pense est moins connu, mais qui est extrêmement puissant. Il est possible de modifier le coeur du fonctionnement de Robot Framework grâce à son API et à un système de plugin (8).

Sans trop rentrer dans les détails techniques – car il est vrai que cet aspect est plus technique – il est possible d’intercepter et de modifier l’exécution et la manière dont Robot Framework réalise ses actions et exécute les tests. Cela offre une multitude de possibilité et pour n’en citer qu’une, je donnerais l’exemple du plugin robotframework-testrail qui permet de pousser les résultats d’exécutions des tests Robot Framework dans l’outil de gestion de tests TestRail.

Dans l’exemple ci-dessous, on a ajouté un tag avec le numéro du test qui correspond à celui du test dans TestRail (test_case_id=1234). En utilisant l’API de Robot Framework, le plugin est capable de récupérer facilement ce numéro et le résultat du test puis de le publier dans TestRail :

Conclusion

Dans mon expérience personnelle, j’ai rencontré des tests Robot Framework dans différents domaines (Télécommunication, TV numérique, Web), sur différents types de technologie (Embarqué, API REST, webservices, serveurs web, microservices) et programmés dans différents langages (Python, C/C++, Javascript), pour ne citer que quelques exemples que je connais. J’ai donc pu constater la polyvalence, l’adaptabilité et les possibilités d’évolution de Robot Framework, qui font de lui un outil générique pour

automatiser les tests de Validation. Ce n’était pas l’objet de cet article, mais nous aurions pu ajouter bien d’autres caractéristiques intéressantes (lisibilité, dynamisme de la communauté, fiabilité, structure…).

Pour conclure, on peut dire que Robot Framework, ayant été réalisé « par des testeurs » 9 et « pour des testeurs » 10, est particulièrement bien adapté à eux. C’est donc un outil de choix lorsqu’on veut faire de l’automatisation de tests.

— Alexis Pallier

Notes

1 : Cela ne veut pas forcément dire que Robot Framework ne pourra pas être utilisé à

d’autres fins et à d’autres niveaux de test bien-sûr. Je pense notamment aux tests

d’API qui sont généralement situés au niveau des tests d’Intégration.

2 : La possibilité de faire du RPA avec Robot Framework est une preuve

supplémentaire qu’il s’inscrit bien dans une optique d’automatisation d’actions

habituellement réalisées par un humain.

3 : Les librairies fournies par Robot Framework sont ce qu’on appelle techniquement en

Test Logiciel des harnais de test.

4 : Le « il suffit » peut paraître un raccourci un peu trop facile. Cependant, de nos jours,

de nombreuses librairies existent avec une interface en Python ou en Java. Ces

langages étant nativement « lisibles » par Robot Framework, le travail d’adaptation est

généralement simple.

5 : KDT = Keyword Driven Testing. Voir

KDT: Keyword Driven Testing

6 : BDD = Behavior Driven Development. Voir ces articles :

https://latavernedutesteur.fr/tag/bdd/

7 : On pourrait également ajouter l’écriture en DDT (Data Driven Testing) mais il

constitue une variante du KDT

8 : Voir l’interface « Listener » de Robot Framework

9 : Pekka Klarke <http://eliga.fi/>, le créateur de Robot Framework, se définit lui-même

comme un « Testeur Agile »

10 : Voir à ce sujet cet article de JP Lambert

A propos de l’auteur: Alexis Pallier:

Je suis Testeur indépendant. J’accompagne les entreprises pour les aider à définir leur stratégie de Test et à la mettre en œuvre concrètement.

Découvrez mes autres articles sur mon Blog: Eh Bien Testez Maintenant !