Structure d'un script Robot Framework

L'anatomie d'un script Robot Framework : une organisation claire pour des tests efficaces

Pour écrire des tests automatisés robustes et compréhensibles avec Robot Framework, il est fondamental de maîtriser la structure d'un script. Imaginez-la comme le plan d'architecte de vos tests : une organisation bien pensée garantit la solidité et la facilité de maintenance de votre projet d'automatisation. Un script Robot Framework est un simple fichier texte, généralement avec une extension `.robot` ou `.txt`, organisé en plusieurs sections distinctes, chacune ayant un rôle précis. Cette structuration est l'une des clés de la lisibilité et de la simplicité d'utilisation de Robot Framework.

Chaque section est introduite par un en-tête spécifique, encadré par trois astérisques (par exemple, `*** Settings ***`). Bien que Robot Framework offre une certaine flexibilité, quatre sections principales constituent l'épine dorsale de la plupart des fichiers de test : `*** Settings ***`, `*** Variables ***`, `*** Test Cases ***`, et `*** Keywords ***`. Comprendre la fonction et l'interaction de ces sections vous permettra de construire des tests logiques, modulaires et faciles à faire évoluer.

Dans ce chapitre, nous allons disséquer chacune de ces sections. Nous verrons ce qu'elles contiennent, comment elles s'articulent entre elles, et pourquoi cette organisation contribue grandement à l'approche collaborative du développement de tests. Préparez-vous à découvrir comment Robot Framework transforme la complexité apparente de l'automatisation en une suite d'instructions claires et bien ordonnées.

Les quatre piliers : exploration des sections indispensables d'un script

La section `*** Settings ***` est le point de départ de votre script. C'est ici que vous configurez l'environnement général de votre suite de tests. Vous y importez les librairies nécessaires (comme `SeleniumLibrary` pour les tests web, ou `BuiltIn` qui est implicitement disponible), les fichiers de ressources externes contenant des keywords ou variables partagés, et vous pouvez y définir des actions globales comme `Suite Setup` (exécuté une fois avant tous les tests de la suite) ou `Test Teardown` (exécuté après chaque cas de test). La documentation de la suite de tests trouve également sa place ici, offrant un aperçu du contenu du fichier.

Exemple de la section `*** Settings ***` :

*** Settings ***
Library    SeleniumLibrary
Library    Collections    # Librairie pour manipuler listes et dictionnaires
Resource    ../../resources/common_keywords.resource
Suite Setup    Open Browser To Application
Suite Teardown    Close All Browsers
Test Setup    Log    Début du cas de test...
Test Teardown    Capture Page Screenshot On Failure
Documentation    Suite de tests pour vérifier les fonctionnalités de base de l'application.
Force Tags    regression    frontend

La section `*** Variables ***` vous permet de déclarer et d'initialiser les variables qui seront utilisées dans vos tests. Utiliser des variables rend vos scripts plus dynamiques, maintenables et lisibles. Vous pouvez y définir des variables scalaires (une seule valeur), des listes ou des dictionnaires. Ces variables peuvent stocker des URLs, des identifiants de connexion, des chemins de fichiers, ou toute autre donnée susceptible de changer ou d'être réutilisée. La portée de ces variables est généralement limitée au fichier où elles sont définies, mais elles peuvent être importées via des fichiers de ressources.

Exemple de la section `*** Variables ***` :

*** Variables ***
${URL_LOGIN}       https://monapplication.com/login
${BROWSER}         chrome
${VALID_EMAIL}     test@certiquizz.com
${VALID_PASSWORD}  P@$$wOrd123
@{USER_ROLES}      Admin    Editor    Viewer
&{USER_DATA}       name=CertiQuizz    role=Admin

Le coeur de votre fichier de test réside dans la section `*** Test Cases ***`. C'est ici que vous décrivez les scénarios de test que vous souhaitez automatiser. Chaque cas de test a un nom unique et descriptif, suivi d'une série d'étapes. Ces étapes sont constituées d'appels à des keywords (qu'ils soient intégrés, issus de librairies, ou définis par l'utilisateur). Un cas de test typique comprendra des actions pour mettre en place une situation, interagir avec l'application, et vérifier les résultats attendus (assertions). Vous pouvez également ajouter des `[Documentation]` et des `[Tags]` spécifiques à chaque cas de test pour mieux les organiser et les filtrer lors de l'exécution.

Exemple de la section `*** Test Cases ***` :

*** Test Cases ***
Connexion Utilisateur Valide
    [Documentation]    Vérifier la connexion avec des identifiants valides.
    [Tags]    login    smoke    P1
    Ouvrir la page de connexion
    Saisir l'adresse email    ${VALID_EMAIL}
    Saisir le mot de passe    ${VALID_PASSWORD}
    Cliquer sur le bouton Se Connecter
    Vérifier que l'utilisateur est connecté

Tentative de Connexion Avec Email Invalide
    [Documentation]    Vérifier le message d'erreur pour un email invalide.
    [Tags]    login    negative
    Ouvrir la page de connexion
    Saisir l'adresse email    utilisateur_invalide
    Saisir le mot de passe    ${VALID_PASSWORD}
    Cliquer sur le bouton Se Connecter
    Vérifier l'affichage du message d'erreur pour email

Enfin, la section `*** Keywords ***` (parfois appelée `*** User Keywords ***`) est l'endroit où vous définissez vos propres keywords personnalisés. C'est une fonctionnalité extrêmement puissante de Robot Framework qui favorise la réutilisabilité et la lisibilité. En regroupant une séquence d'actions ou de vérifications sous un nom de keyword clair, vous pouvez simplifier vos cas de test et éviter la duplication de code (principe DRY - Don't Repeat Yourself). Ces keywords utilisateurs peuvent accepter des arguments et retourner des valeurs, les rendant très flexibles.

Exemple de la section `*** Keywords ***` :

*** Keywords ***
Ouvrir la page de connexion
    Open Browser    ${URL_LOGIN}    ${BROWSER}
    Maximize Browser Window
    Page Should Contain    Connexion

Saisir l'adresse email
    [Arguments]    ${email}
    Input Text    id:email_field    ${email}

Saisir le mot de passe
    [Arguments]    ${password}
    Input Password    id:password_field    ${password}

Cliquer sur le bouton Se Connecter
    Click Button    id:login_button

Vérifier que l'utilisateur est connecté
    Page Should Contain Element    id:user_dashboard
    Location Should Be    ${URL_LOGIN}/dashboard

Vérifier l'affichage du message d'erreur pour email
    Page Should Contain    L'adresse email saisie est invalide.

Il est important de noter que toutes ces sections ne sont pas obligatoires dans chaque fichier `.robot`. Par exemple, un fichier de ressources (`.resource`) contiendra typiquement des sections `*** Settings ***` (pour importer d'autres ressources ou librairies), `*** Variables ***` et `*** Keywords ***`, mais pas de `*** Test Cases ***`.

La syntaxe : la magie des espaces et la clarté des commentaires

La syntaxe de Robot Framework est conçue pour être aussi proche que possible du langage naturel, ce qui la rend particulièrement accessible, même pour les personnes n'ayant pas une forte expérience en programmation. L'un des aspects les plus distinctifs de cette syntaxe est l'utilisation des espaces comme séparateurs. En règle générale, deux espaces ou plus sont utilisés pour séparer les keywords de leurs arguments, et les arguments entre eux. Cette convention, bien que simple, contribue énormément à la lisibilité des scripts.

Par exemple, une ligne de test pourrait ressembler à ceci : `Log Ceci est un message de log`. Ici, `Log` est le keyword, et `Ceci est un message de log` est son argument. Si un keyword prend plusieurs arguments, ils sont également séparés par au moins deux espaces : `Should Be Equal As Strings ${actual_value} ${expected_value}`. Cette structure aérée rend les scripts faciles à parcourir et à comprendre d'un seul coup d'oeil.

Les commentaires sont un autre élément essentiel pour maintenir la clarté de vos scripts. Dans Robot Framework, tout ce qui suit un caractère dièse (`#`) sur une ligne est considéré comme un commentaire et est ignoré lors de l'exécution. Vous pouvez placer un commentaire sur sa propre ligne pour expliquer une section de code complexe, ou à la fin d'une ligne pour clarifier une étape spécifique. Les commentaires sont cruciaux pour la documentation interne de vos tests et peuvent également être utilisés pour désactiver temporairement des lignes de code pendant le débogage.

Exemple d'utilisation des espaces et des commentaires :

*** Test Cases ***
Mon Premier Test Structuré
    # Ceci est un commentaire expliquant le but du test.
    Log To Console    Début du test    # Affiche un message dans la console
    ${variable_test}    Set Variable    valeur initiale    # Affectation d'une variable
    
    # La ligne suivante est temporairement désactivée
    # Old Keyword    argument1    argument2
    
    Keyword Avec Arguments    arg1    arg2    # Les arguments sont séparés par au moins deux espaces
    Keyword Sans Argument
    Should Be True    ${variable_test} == "valeur initiale"    Message si l'assertion échoue

Concernant la casse, les noms des sections (comme `*** Settings ***`) et les noms des keywords sont insensibles à la casse. Par exemple, `Log`, `log` et `LOG` feront tous appel au même keyword. Cependant, il est de bonne pratique d'adopter une convention de nommage cohérente (par exemple, le CamelCase ou le Title Case pour les keywords) pour améliorer encore la lisibilité de vos scripts. Les valeurs des variables, en revanche, sont généralement sensibles à la casse, en fonction de la manière dont elles sont utilisées et du système sous-jacent.