Utilisation de variables pour les sélecteurs et les textes attendus

L'importance des variables dans la maintenabilité des scripts de test

Lorsque vous écrivez des scripts d'automatisation de tests, en particulier pour des interfaces web, vous manipulez constamment des localisateurs d'éléments (sélecteurs ID, CSS, XPath, etc.) et des données de test (comme des textes attendus, des URL, des identifiants). Intégrer ces valeurs directement dans le corps de vos tests (ce qu'on appelle des valeurs "en dur" ou "hardcodées") peut sembler rapide au début, mais cela devient rapidement un cauchemar en termes de maintenance.

Imaginez qu'un sélecteur d'élément change sur votre application, ou qu'un message textuel soit modifié. Si cette valeur est utilisée dans dix tests différents, vous devrez la modifier manuellement à dix endroits. C'est source d'erreurs et de perte de temps. C'est là que l'utilisation des variables dans Robot Framework prend tout son sens. En définissant vos sélecteurs et textes attendus comme des variables, vous centralisez leur définition. Une modification à un seul endroit (la déclaration de la variable) se répercute alors automatiquement partout où cette variable est utilisée.

L'utilisation de variables améliore également grandement la lisibilité de vos scripts. Un nom de variable bien choisi (par exemple, `${LOGIN_BUTTON_SELECTOR}` ou `${WELCOME_MESSAGE_TEXT}`) est beaucoup plus explicite qu'un sélecteur CSS complexe ou une longue chaîne de caractères directement insérée dans un keyword.

Déclarer et utiliser des variables pour les sélecteurs d'éléments

Dans Robot Framework, les variables sont typiquement déclarées dans la section `*** Variables ***` de vos fichiers de test (`.robot`) ou de ressources (`.resource`). Pour les sélecteurs d'éléments, qui sont des chaînes de caractères, on utilise la syntaxe des variables scalaires : `${NOM_DE_LA_VARIABLE}`.

Prenons l'exemple d'un formulaire de connexion. Au lieu d'écrire :

*** Test Cases ***
Mon Test De Connexion
    Input Text    id:username    monUtilisateur
    Input Text    id:password    monMotDePasse
    Click Button  css:button[type='submit']

Vous définiriez d'abord les variables pour les sélecteurs :

*** Variables ***
${USERNAME_FIELD_SELECTOR}    id:username
${PASSWORD_FIELD_SELECTOR}    id:password
${LOGIN_BUTTON_SELECTOR}      css:button[type='submit']

Puis vous les utiliseriez dans votre cas de test :

*** Test Cases ***
Mon Test De Connexion Avec Variables
    Input Text    ${USERNAME_FIELD_SELECTOR}    monUtilisateur
    Input Text    ${PASSWORD_FIELD_SELECTOR}    monMotDePasse
    Click Button  ${LOGIN_BUTTON_SELECTOR}

Cette approche présente plusieurs avantages :

• Centralisation : Si l'ID du champ `username` change de `id:username` à `id:user_login`, vous n'avez qu'à modifier la valeur de la variable `${USERNAME_FIELD_SELECTOR}`. Tous les tests utilisant cette variable seront automatiquement mis à jour.
• Lisibilité : `${USERNAME_FIELD_SELECTOR}` est plus descriptif que `id:username` directement dans le code du test, surtout si le sélecteur est complexe.
• Réutilisabilité : Ces variables peuvent être définies dans un fichier de ressources et importées dans plusieurs suites de tests, assurant une cohérence des sélecteurs à travers tout votre projet d'automatisation.

Le préfixe du sélecteur (comme `id:`, `css:`, `xpath:`) fait partie intégrante de la valeur de la variable.

Déclarer et utiliser des variables pour les textes attendus et autres données

De la même manière que pour les sélecteurs, il est judicieux d'utiliser des variables pour les textes que vous vous attendez à trouver sur une page, les URL, les identifiants de test, ou toute autre donnée statique mais susceptible de changer ou utilisée à plusieurs endroits.

Par exemple, pour vérifier un message de bienvenue après une connexion réussie :

*** Variables ***
${SUCCESS_MESSAGE_SELECTOR}    css:div#flash-messages
${EXPECTED_WELCOME_TEXT}     Welcome, Test User!

*** Test Cases ***
Verification Message De Bienvenue
    # ... étapes de connexion ...
    Wait Until Page Contains Element    ${SUCCESS_MESSAGE_SELECTOR}    timeout=10s
    Element Should Contain            ${SUCCESS_MESSAGE_SELECTOR}    ${EXPECTED_WELCOME_TEXT}

Si le texte de bienvenue change, par exemple en "Hello, Test User!", vous n'aurez qu'à mettre à jour la variable `${EXPECTED_WELCOME_TEXT}`.

Pour les URL, c'est particulièrement utile si vous avez différents environnements de test (développement, recette, production) :

*** Variables ***
${BASE_URL}       https://test.mondomaine.com
${LOGIN_PAGE_PATH}  /login

*** Test Cases ***
Acces Page De Connexion
    Open Browser    ${BASE_URL}${LOGIN_PAGE_PATH}    Chrome

Vous pouvez même passer la valeur de `${BASE_URL}` en ligne de commande lors de l'exécution des tests (`robot --variable BASE_URL:https://prod.mondomaine.com tests.robot`), ce qui permet de cibler différents environnements sans modifier les scripts.

L'utilisation de variables pour les données de test favorise non seulement la maintenabilité et la lisibilité, mais aussi la séparation entre la logique du test et les données de test. Cela ouvre la voie à des techniques plus avancées comme les tests pilotés par les données (Data-Driven Testing), où les données de test peuvent être stockées dans des fichiers externes (Excel, CSV, YAML) et lues par Robot Framework pour exécuter le même test avec plusieurs jeux de données.

Bonnes pratiques pour la gestion des variables de sélecteurs et de textes

Pour tirer le meilleur parti de l'utilisation des variables pour les sélecteurs et les textes attendus, voici quelques bonnes pratiques à considérer :

• Nommage clair et cohérent : Utilisez des noms de variables qui décrivent clairement leur contenu et leur usage. Adoptez une convention de nommage (par exemple, tout en majuscules avec des underscores : `${NOM_VARIABLE_SELECTEUR}`, ou camelCase : `${nomVariableTexte}`).
• Portée des variables : Les variables définies dans la section `*** Variables ***` d'un fichier de test sont locales à ce fichier. Pour partager des variables (comme des sélecteurs communs à plusieurs pages ou des URL de base) entre plusieurs suites de tests, définissez-les dans un fichier de ressources (`.resource`) et importez ce fichier dans vos suites de tests.
• Organisation : Regroupez les variables par type ou par page/fonctionnalité pour faciliter leur recherche et leur gestion, surtout dans les fichiers de ressources volumineux. Par exemple, vous pourriez avoir des sections de variables pour la page de connexion, la page produit, etc.
• Eviter la sur-utilisation : Bien que les variables soient utiles, n'en abusez pas pour des valeurs qui ne sont utilisées qu'une seule fois et qui ne sont pas susceptibles de changer. L'objectif est d'améliorer la maintenabilité, pas de complexifier inutilement le code.
• Documentation : Pour les variables dont le rôle n'est pas immédiatement évident d'après leur nom (surtout dans les fichiers de ressources partagés), n'hésitez pas à ajouter des commentaires pour expliquer leur utilité.

En intégrant systématiquement l'utilisation de variables pour vos sélecteurs et vos textes attendus, vous construirez des scripts Robot Framework non seulement plus robustes face aux évolutions de l'application testée, mais aussi plus faciles à comprendre, à maintenir et à faire évoluer par vous-même ou par d'autres membres de votre équipe.