Portée des variables : quand et où les utiliser

La portée des variables : un concept clé pour la structure et la maintenabilité

En programmation et en automatisation, la "portée" (ou "scope" en anglais) d'une variable désigne la région du code où cette variable est accessible et peut être utilisée. Une bonne compréhension de la portée des variables dans Robot Framework est cruciale pour écrire des tests organisés, éviter les conflits de noms, gérer l'état de manière prévisible et assurer la maintenabilité de vos scripts sur le long terme. Utiliser la bonne portée pour chaque variable permet de limiter les effets de bord et de rendre le flux de données plus clair.

Robot Framework propose plusieurs niveaux de portée, allant d'une accessibilité très locale (limitée à un keyword) à une visibilité globale (accessible partout durant l'exécution). Le choix de la portée dépendra de la nature de la donnée que la variable représente : est-ce une configuration globale, une donnée spécifique à une suite de tests, une valeur temporaire pour un seul cas de test, ou un simple intermédiaire de calcul dans un keyword ?

Ce sous-chapitre détaillera les différentes portées disponibles (locale, test, suite, globale), expliquera comment les variables obtiennent leur portée (implicitement ou explicitement via des keywords) et fournira des recommandations sur quand et où utiliser chaque type de portée pour optimiser la structure et la robustesse de vos tests.

Les différents niveaux de portée dans Robot Framework

Robot Framework gère la visibilité des variables à travers quatre principaux niveaux de portée :

1. Portée Locale (Local Scope) :
C'est la portée la plus restreinte. Une variable avec une portée locale n'est accessible qu'à l'intérieur du keyword utilisateur où elle a été créée. Les arguments d'un keyword utilisateur ont également une portée locale à ce keyword. Les variables créées avec le keyword `Set Variable` à l'intérieur d'un keyword utilisateur ont par défaut une portée locale. Elles cessent d'exister une fois que le keyword a terminé son exécution, à moins qu'elles ne soient explicitement retournées.

2. Portée du Cas de Test (Test Case Scope) :
Une variable avec cette portée est accessible n'importe où à l'intérieur du cas de test spécifique où elle a été définie, y compris dans les keywords appelés par ce cas de test (si le keyword ne redéfinit pas localement une variable du même nom). Elle est créée à l'aide du keyword `Set Test Variable`. Elle est "oubliée" dès que le cas de test actuel se termine. C'est utile pour partager des données entre plusieurs keywords au sein d'un même scénario de test sans polluer d'autres tests.

3. Portée de la Suite (Suite Scope) :
Les variables ayant une portée de suite sont accessibles depuis n'importe quel cas de test ou keyword au sein de la suite de tests où elles ont été définies. Une suite de tests correspond généralement à un fichier `.robot`. Les variables déclarées directement dans la section `*** Variables ***` d'un fichier de test ont implicitement une portée de suite. Vous pouvez aussi explicitement définir une variable de suite avec le keyword `Set Suite Variable`. Ces variables sont initialisées lorsque la suite commence et persistent jusqu'à ce que la suite se termine. Elles sont également accessibles dans les `Suite Setup` et `Suite Teardown`.

4. Portée Globale (Global Scope) :
C'est la portée la plus large. Une variable globale est accessible depuis n'importe quelle suite de tests, n'importe quel cas de test, et n'importe quel keyword pendant toute la durée de l'exécution de la session Robot Framework. Elles sont créées avec le keyword `Set Global Variable`. Bien que puissantes, les variables globales doivent être utilisées avec parcimonie, car un usage excessif peut rendre les dépendances entre tests obscures et compliquer le débogage et la maintenance.

Il est important de noter que si des variables de portées différentes ont le même nom, la règle de "proximité" s'applique : une variable locale masquera une variable de test du même nom, qui masquera une variable de suite, qui elle-même masquera une variable globale. Robot Framework cherchera d'abord la variable dans la portée la plus locale, puis remontera les niveaux de portée.

Comment les variables acquièrent leur portée et exemples d'utilisation

*** Variables ***
${URL_BASE}         https://certiquizz.com  # Portée de suite
@{OPTIONS_MENU}     Accueil    Formations    Blog  # Portée de suite

*** Test Cases ***
Test 1
    Log    L'URL de base est : ${URL_BASE}
    Log    La première option du menu est : ${OPTIONS_MENU}[0]

Test 2
    Should Contain    ${URL_BASE}    certiquizz

Ici, `${URL_BASE}` et `@{OPTIONS_MENU}` sont accessibles dans `Test 1` et `Test 2` car elles sont définies au niveau de la suite.

*** Test Cases ***
Test avec keyword local
    Mon Keyword Qui Crée Une Variable
    # Log    ${VAR_LOCALE}  # Erreur : ${VAR_LOCALE} n'est pas visible ici

*** Keywords ***
Mon Keyword Qui Crée Une Variable
    ${VAR_LOCALE}    Set Variable    Je suis une variable locale à ce keyword.
    Log    Dans le keyword : ${VAR_LOCALE}
    # ${VAR_LOCALE} cesse d'exister après ce Log (sauf si retournée)

*** Test Cases ***
Scénario de Test Utilisant Variable de Test
    ${id_utilisateur_cree}    Créer Nouvel Utilisateur    Jean    Bon
    Set Test Variable    ${ID_UTILISATEUR_ACTIF}    ${id_utilisateur_cree}
    Vérifier Profil Utilisateur
    Supprimer Utilisateur Actif

Autre Scénario
    # Log    ${ID_UTILISATEUR_ACTIF} # Erreur : Non défini dans ce cas de test

*** Keywords ***
Créer Nouvel Utilisateur
    [Arguments]    ${prenom}    ${nom}
    [Return]    USER_${prenom}${nom}
    ${id_genere}    Set Variable    USER_${prenom}${nom}
    Log    Utilisateur ${id_genere} créé.
    RETURN    ${id_genere}

Vérifier Profil Utilisateur
    Log    Vérification du profil pour l'utilisateur : ${ID_UTILISATEUR_ACTIF}

Supprimer Utilisateur Actif
    Log    Suppression de l'utilisateur : ${ID_UTILISATEUR_ACTIF}

Ici, `${ID_UTILISATEUR_ACTIF}` est partagée entre les keywords `Vérifier Profil Utilisateur` et `Supprimer Utilisateur Actif` mais uniquement dans le contexte du cas de test `Scénario de Test Utilisant Variable de Test`.

*** Settings ***
Suite Setup       Initialiser Session API

*** Test Cases ***
Test API 1
    Effectuer Appel Get Sur    /ressources
    Log    Token utilisé pour Test API 1 : ${TOKEN_API_SUITE}

Test API 2
    Effectuer Appel Post Sur   /utilisateurs
    Log    Token utilisé pour Test API 2 : ${TOKEN_API_SUITE}

*** Keywords ***
Initialiser Session API
    ${token_recu}    Obtenir Token D'Authentification    # Simule l'obtention d'un token
    Set Suite Variable    ${TOKEN_API_SUITE}    ${token_recu}

Obtenir Token D'Authentification
    [Return]    TOKEN_SECRET_123XYZ
    RETURN    TOKEN_SECRET_123XYZ

Effectuer Appel Get Sur
    [Arguments]    ${endpoint}
    Log    GET ${endpoint} avec token ${TOKEN_API_SUITE}

Effectuer Appel Post Sur
    [Arguments]    ${endpoint}
    Log    POST ${endpoint} avec token ${TOKEN_API_SUITE}

Le `${TOKEN_API_SUITE}` est défini une fois dans le `Suite Setup` et est réutilisable par tous les cas de test de cette suite.

# Fichier: common_setup.robot (pourrait être un Suite Setup global ou importé)
*** Keywords ***
Configuration Globale Initiale
    Set Global Variable    ${MODE_EXECUTION}    PRODUCTION
    Log    Mode d'exécution global défini sur : ${MODE_EXECUTION}

# Fichier: suite_A.robot
*** Settings ***
Suite Setup    Configuration Globale Initiale # Si appelé explicitement
Resource        common_setup.robot # ou importé si c'est une ressource

*** Test Cases ***
Test dans Suite A
    Log    Mode d'exécution dans Suite A : ${MODE_EXECUTION}

# Fichier: suite_B.robot
*** Settings ***
# Pas besoin d'appeler Configuration Globale Initiale si déjà fait une fois globalement

*** Test Cases ***
Test dans Suite B
    Run Keyword If    '${MODE_EXECUTION}' == 'PRODUCTION'    Log    Actions spécifiques à la production.
    ...    ELSE    Log    Actions spécifiques au développement.

Ici, `${MODE_EXECUTION}` serait accessible dans `suite_A.robot` et `suite_B.robot` (et toute autre suite exécutée dans la même session) après son initialisation.

Recommandations : quand utiliser quelle portée ?

Choisir la bonne portée pour vos variables est essentiel pour la clarté et la robustesse de vos tests.

• Portée Locale (dans les keywords utilisateurs) :
  Quand l'utiliser : Pour les variables temporaires nécessaires uniquement à l'intérieur d'un keyword (compteurs, résultats intermédiaires, etc.). C'est la portée à privilégier par défaut pour les variables créées au sein d'un keyword afin de garantir l'encapsulation et d'éviter les effets de bord.
  Comment : `Set Variable` à l'intérieur d'un keyword. Les arguments du keyword ont aussi cette portée. Retournez explicitement les valeurs si elles doivent être utilisées à l'extérieur avec `[Return]` et `RETURN`.
• Portée du Cas de Test :
  Quand l'utiliser : Lorsque vous avez besoin de partager une information entre plusieurs étapes (keywords) d'un même cas de test, mais que cette information n'est pas pertinente pour d'autres cas de test. Par exemple, un ID d'objet créé au début du test et utilisé pour des vérifications et un nettoyage à la fin de ce même test.
  Comment : `Set Test Variable`.
• Portée de la Suite (section `*** Variables ***` ou `Set Suite Variable`) :
  Quand l'utiliser : Pour les configurations ou les données qui sont constantes et partagées par la majorité ou la totalité des cas de test d'une même suite (fichier `.robot`). Exemples : URL de base de l'application testée, identifiants de connexion par défaut pour la suite, configurations spécifiques à l'environnement de cette suite. Egalement utile dans `Suite Setup` pour initialiser des ressources partagées par tous les tests de la suite.
  Comment : Déclarer dans la section `*** Variables ***` du fichier de test, ou utiliser `Set Suite Variable` (typiquement dans un `Suite Setup`).
• Portée Globale :
  Quand l'utiliser : Avec une extrême prudence. Pour des configurations très générales qui s'appliquent à l'ensemble de l'exécution des tests, sur plusieurs suites. Par exemple, un indicateur de mode d'exécution (test, staging, production) qui pourrait influencer le comportement de certaines librairies ou la sélection de données de test. Il est souvent préférable de passer de telles configurations via des fichiers de variables externes ou des arguments en ligne de commande plutôt que de trop reposer sur des variables globales pour maintenir la modularité.
  Comment : `Set Global Variable`.

• Privilégiez la portée la plus restreinte possible : Cela minimise les risques de conflits de noms et d'effets de bord inattendus, et rend les tests plus faciles à comprendre et à déboguer individuellement.
• Encapsulation dans les keywords : Les keywords doivent être aussi autonomes que possible. Ils reçoivent des données en arguments et retournent des résultats, limitant ainsi leur dépendance à des variables de portée supérieure.
• Clarté des noms : Utilisez des noms de variables explicites, surtout pour celles ayant une portée large (suite ou globale), pour éviter toute ambiguïté.
• Fichiers de ressources pour les variables partagées : Si des variables (notamment de configuration) doivent être partagées entre plusieurs suites de tests, il est souvent plus propre de les définir dans un fichier de ressources (`.resource`) et d'importer ce fichier dans les suites concernées, plutôt que d'utiliser massivement des variables globales.

En maîtrisant la portée des variables, vous gagnez un contrôle fin sur le flux de données dans vos tests, ce qui est fondamental pour construire des suites d'automatisation scalables, robustes et maintenables avec Robot Framework.