Exécution des tests

Exécution via RIDE

L’exécution des tests via RIDE a été abordée brièvement dans le chapitre Show Robot Framework pour permettre une première découverte du résultat final et offrir une visualisation rapide de l’exécution d’un test automatisé. Cette section vise à approfondir ce sujet, en examinant les diverses options offertes par Robot Framework pour l’exécution des tests depuis l’interface de l’éditeur RIDE. Le bouton Run Tests, présent sur cette interface et situé entre les icônes T et bug, joue un rôle central : il sert de point d’entrée pour lancer un ou plusieurs tests directement depuis l’interface, quel que soit l’onglet actif.

Bouton Run Tests pour exécuter les tests depuis le menu principal de RIDE

Il est également possible d’activer ce bouton via un raccourci-clavier en appuyant sur [F8]. Un équivalent de ce bouton se trouve également dans la page correspondant à l’onglet Run, sous le nom Start robot, avec la même icône.

Bouton Start robot pour exécuter les tests depuis l’onglet Run

Dans l’onglet Run, un ensemble de configurations peut être ajouté pour personnaliser l’exécution des tests. Toutefois, avant d’approfondir cette section, il est important de noter qu’une exécution basique, sans paramètres ni configuration spécifique, peut être lancée d’un simple clic sur le bouton Run Tests. Par défaut, si aucun test n’est sélectionné, Robot Framework signale cette situation et propose de poursuivre l’exécution de l’ensemble des tests ou d’interrompre...

Exécution en mode Debug

Dans le domaine des tests automatisés avec Robot Framework, le mode « Debug » permet de gérer les erreurs de manière plus approfondie en offrant des informations détaillées sur l’exécution des cas de test. Ce mode fournit un log plus détaillé ainsi qu’un mode interactif pour suivre pas à pas l’exécution des tests et interagir avec le système testé en temps réel, afin de mieux comprendre ce qui se passe en arrière-plan. Contrairement à une exécution standard, où seules les erreurs finales sont rapportées, l’exécution en mode Debug permet de capturer davantage d’informations.

Lors de l’automatisation des tests, il est rare que tout fonctionne parfaitement dès le premier essai. Les scripts de test peuvent rencontrer des erreurs pour diverses raisons : une mauvaise configuration de l’environnement, des données d’entrée incorrectes, des erreurs de syntaxe ou de logique dans le script, ou encore des problèmes externes non liés au script, tels que des interruptions réseau, des services tiers indisponibles, ou des accès défaillants à des bases de données. C’est dans ces situations que le mode Debug devient intéressant. Plutôt que d’exécuter l’ensemble des tests puis de parcourir les rapports en essayant d’identifier chaque échec, le mode Debug permet de suivre l’exécution des tests de manière plus détaillée. Cela facilite la détection des erreurs à chaque étape, qu’elles soient liées au script ou à des facteurs externes, et permet un diagnostic plus rapide et précis.

Robot Framework propose...

Analyse des rapports

Les rapports de Robot Framework fournissent des informations détaillées, permettant une meilleure analyse des résultats d’exécution des tests. Ils génèrent des fichiers prêts à l’emploi et faciles à parcourir, tels que report.html et log.html, ainsi que des fichiers bruts utilisés pour créer ces fichiers HTML. Ces fichiers bruts contiennent toutes les informations nécessaires sur l’exécution des tests, offrant la possibilité de créer des rapports personnalisés.

<kw name="Faire une recherche google"> 
<kw name="Open Browser" owner="SeleniumLibrary">  
<msg time="2024-10-03T14:06:59.599427" level="INFO">Opening 
browser 'chrome' to base url 'https://google.Com'.</msg>
<arg>https://google.Com</arg> 
<arg>chrome</arg> 
<arg>options=add_argument("--disable-search-engine-choice-screen")</arg> 
<doc>Opens a new browser instance to the optional ``url``.</doc> 
<status status="PASS" start="2024-10-03T14:06:59.599427" elapsed="1.931053"/> 
</kw> 
<kw name="Maximize Browser Window" owner="SeleniumLibrary">  
<doc>Maximizes current browser window.</doc> 
<status status="PASS" start="2024-10-03T14:07:01.531484" elapsed="0.032993"/> 
</kw> 
<kw name="Click Element" owner="SeleniumLibrary"> 
<msg time="2024-10-03T14:07:01.565518" level="INFO">Clicking 
element 'id=L2AGLb'.</msg> 
<arg>id=L2AGLb</arg> 
<doc>Click the element identified by ``locator``.</doc> ...

Exécution via ligne de commande (ou CLI)

La plupart des outils ou technologies du marché proposent une utilisation via la ligne de commande, qui est une interface utilisateur permettant d’interagir avec un programme en entrant des commandes sous forme de texte, plutôt que d’utiliser une interface graphique (comme déjà vu avec l’éditeur RIDE). Elle fonctionne grâce à un interpréteur de commandes, tel que le terminal sous Linux ou l’invite de commande sous Windows, où les utilisateurs saisissent des instructions que le système exécute.

L’un des principaux avantages de la ligne de commande est qu’elle permet une interaction directe et efficace avec le système d’exploitation, sans passer par des interfaces graphiques. Cela la rend rapide et légère, consommant très peu de ressources système, ce qui permet une exécution fluide, même sur des machines aux performances limitées. Elle offre également une grande flexibilité et un contrôle granulaire, permettant de combiner des commandes simples pour créer des opérations complexes via des scripts, automatisant ainsi de nombreuses tâches répétitives. Par exemple, il est possible de créer un script qui parcourt un répertoire entier, applique des transformations sur chaque fichier et enregistre les résultats sans intervention humaine.

De plus, la ligne de commande permet un accès facile aux systèmes distants via des outils comme SSH, facilitant ainsi la gestion à distance des serveurs ou autres dispositifs dans un environnement réseau, même avec une connexion lente.

En outre, elle est largement disponible et universelle, intégrée à la plupart des systèmes d’exploitation, qu’il s’agisse de Linux, Windows ou macOS, ce qui la rend portable et compatible à travers différents environnements.

Enfin, la ligne de commande est particulièrement prisée dans les environnements de développement et de test, car elle s’intègre aisément avec des outils d’automatisation, des systèmes de contrôle de version comme Git, et des outils de CI/CD pour industrialiser l’exécution des tests.

La commande robot, le cœur de Robot Framework...

Utilisation de Setup et Teardown

Dans Robot Framework, les fonctionnalités Setup et Teardown sont essentielles pour structurer et organiser les tests. Elles permettent de définir des étapes d’initialisation et de nettoyage avant et après l’exécution des tests, assurant ainsi que l’environnement est prêt avant chaque exécution et qu’il est remis dans un état stable après la fin de l’exécution des tests.

Robot Framework propose plusieurs niveaux de Setup et Teardown :

Ces mécanismes permettent d’automatiser la configuration de l’environnement de test (par exemple, ouvrir une session, préparer des données, etc.) et de nettoyer après les tests (fermer une session, réinitialiser les données, etc.).

Chaque composant sera présenté en détail et les explications seront illustrées par des exemples.

*** Settings *** 
Suite Setup       Ouvrir Connexion Base De Données 
Suite Teardown    Fermer Connexion Base De Données 
 
*** Test Cases *** 
Test 1 - Vérification de données 
    Vérifier Les Données    "utilisateur1" 
 
Test 2 - Vérification d'insertion 
    Insérer Données    "nouvel_utilisateur" 
    Vérifier Les Données    "nouvel_utilisateur" 
 
*** Keywords *** 
Ouvrir Connexion Base De Données 
    # Define your actions...

Utilisation des tags

La notion des tags a été introduite brièvement dans la section précédente, consacrée à l’exécution via la ligne de commande. Cette section explore cette fonctionnalité plus en détail, en expliquant également comment l’utiliser à travers l’interface de RIDE.

Les tags servent à marquer les cas de test avec des mots-clés ou des catégories spécifiques. Ils permettent d’organiser, filtrer et exécuter des tests selon des critères définis. Dans des projets complexes, des tags comme Regression ou NewFeature sont utilisés pour organiser les tests par type ou priorité. Des tags comme Critical permettent d’exécuter uniquement les tests critiques avant une livraison. Les tests spécifiques à des environnements (WindowsOnly, LinuxOnly) ou des contextes (Mobile, Web, API) peuvent également être filtrés. Cette flexibilité simplifie la gestion des tests dans différents environnements, notamment des environnements CI/CD.

Il existe deux manières d’ajouter des tags aux cas de test directement via l’interface, en utilisant les cases Tags. Un ou plusieurs tags peuvent être assignés à un cas de test. Voici comment procéder :

Ajout de tags depuis la vue Editor

Il est aussi possible d’ajouter des tags depuis la vue Text Edit. Pour cela, il suffit de se positionner sur la première ligne après le titre du cas de test et de saisir la clause [Tags], suivie du ou des tags souhaités. Voici un exemple pour illustrer l’ajout de tags dans cette vue :

*** Settings *** 
Library    SeleniumLibrary 
 
*** Test Cases *** 
Test Login with Valid Credentials 
    [Tags]    Login    Sanity 
    # define your actions here 
 
Test Login with Empty Credentials 
    [Tags]    Login    Regression 
    # define your actions here 

Pour bien saisir l’utilisation de cette...

Utilisation des templates

Dans Robot Framework, un template est une fonctionnalité qui permet de réutiliser des étapes communes dans plusieurs cas de test, évitant ainsi la duplication de code. Il est particulièrement utile lorsque plusieurs tests suivent la même structure, mais diffèrent par les données d’entrée. Cela transforme l’approche classique « Keyword Driven », adoptée par défaut par Robot Framework, en une approche « Data Driven ». Plutôt que de réécrire des actions identiques, un modèle (template) est défini et est appliqué avec des données spécifiques. Les paramètres sont ensuite utilisés dans le mot-clé pour personnaliser chaque test.

La création d’un template dans Robot Framework passe les étapes suivantes :

*** Keywords *** 
Your_keyword_template 
    [Arguments]    ${arg1}    ${arg2} 
    Log    Exécution avec ${arg1} et ${arg2} 

*** Test Cases ***Templated_test 
       [Template]    Your_keyword_template 
                valeur1   valeur2 
                valeur3    valeur4 

Si l’on souhaite appliquer ce template globalement à toute la suite de tests, sans avoir à le spécifier dans chaque section  ***Test Cases ***, il est possible d’utiliser la clause Test Template et de déclarer le mot-clé dans la section Settings comme suit :...

Gestion des flaky tests

Les flaky tests sont un fléau silencieux dans le domaine des tests automatisés, une sorte de mirage qui épuise les efforts des équipes tout en minant la confiance dans le processus de validation. Lorsqu’un test devient flaky, il se transforme en une source de doutes et d’incertitudes : sans raison apparente, il réussit un jour et échoue le lendemain. La nature capricieuse des flaky tests ne tient ni à une véritable défaillance du code ni à une erreur de conception des tests, mais plutôt à des facteurs périphériques et instables, souvent difficiles à identifier. Ces causes peuvent être multiples, allant d’interactions avec des API externes, aux comportements imprévisibles de la base de données, ou encore à des problèmes de synchronisation dans l’environnement d’exécution.

Au-delà de l’irritation qu’ils suscitent, les flaky tests ont un impact considérable sur le cycle de développement et la dynamique des équipes. Leur caractère insaisissable oblige les testeurs et développeurs à consacrer un temps précieux à des analyses infructueuses, dans l’espoir de découvrir pourquoi un test a échoué alors qu’il fonctionnait parfaitement quelques heures auparavant. Cette incertitude fragilise la fiabilité des rapports de test et ralentit l’ensemble du processus de validation. Les équipes hésitent à intégrer de nouvelles fonctionnalités sans validation complète, et cette prudence, bien que justifiée, engendre des retards dans les cycles de livraison.

Pour une entreprise, les conséquences de cette instabilité vont bien au-delà du simple surcoût en temps et en ressources. Elle influence la confiance même dans les tests automatisés. Lorsqu’un test est perçu comme instable, toute la suite de tests est suspectée, rendant chaque rapport de tests potentiellement biaisé et chaque signal d’alerte moins fiable. Les flaky tests ne sont plus de simples anomalies isolées, mais deviennent des failles systémiques, porteuses de risques pour la qualité du produit final et pour la sérénité des équipes....