Nommage clair et cohérent (tests, keywords, variables)

Principes généraux d'un bon nommage

Un nommage efficace dans Robot Framework, comme dans tout langage de programmation ou d'automatisation, repose sur quelques principes fondamentaux. L'objectif principal est de rendre le code auto-documenté : un nom bien choisi doit instantanément transmettre l'intention et la fonction de l'élément qu'il désigne. Cela réduit le besoin de commentaires excessifs et facilite la compréhension par d'autres membres de l'équipe, ou par vous-même lorsque vous revisitez le code après un certain temps.

Clarté avant tout : Le nom doit être sans ambiguïté. Evitez les abréviations obscures ou les acronymes non standards. Préférez un nom un peu plus long mais explicite à un nom court mais cryptique. Par exemple, Verifier Solde Compte Utilisateur est préférable à VerifSoldeU.

Cohérence : Adoptez une convention de nommage et respectez-la scrupuleusement à travers tout votre projet. Que vous choisissiez le PascalCase (MaSuperVariable), le camelCase (maSuperVariable), le snake_case (ma_super_variable), ou le style avec des espaces (Ma Super Variable, typique de Robot Framework pour les noms de tests et keywords), l'important est la constance. Cette cohérence rend le code plus prévisible et plus facile à lire.

Concision (avec modération) : Bien que la clarté soit primordiale, essayez de ne pas rendre les noms excessivement longs. Trouvez un équilibre. Par exemple, Obtenir Le Premier Produit De La Liste Recommandée est bon, mais pourrait peut-être être simplifié si le contexte le permet.

Utilisation de l'anglais ou du français : Choisissez une langue pour vos noms (typiquement l'anglais dans les projets internationaux, mais le français est parfaitement acceptable pour des équipes francophones) et tenez-vous-y. Mélanger les langues dans les noms peut prêter à confusion.

Nommer les fichiers et les suites de tests

Les noms de vos fichiers de test (.robot) et des suites de tests qu'ils contiennent (définies par le nom du fichier ou via la section Suite Setup/Teardown ou documentation) doivent refléter le module, la fonctionnalité ou l'ensemble de scénarios qu'ils couvrent. Utilisez des noms descriptifs qui indiquent clairement le périmètre des tests.

Pour les fichiers : Utilisez le snake_case (gestion_comptes_utilisateurs.robot) ou le kebab-case (gestion-comptes-utilisateurs.robot) pour une bonne lisibilité dans le système de fichiers. Ces noms sont souvent utilisés pour générer les noms des suites par défaut.

# Exemples de noms de fichiers
login_tests.robot
user_profile_management.robot
search_functionality.robot

Pour les noms de suites (dans les rapports) : Robot Framework utilise par défaut le nom du fichier, converti en un format avec des espaces et une capitalisation de type titre (Title Case). Par exemple, login_tests.robot deviendra "Login Tests". Vous pouvez surcharger cela avec le setting Name dans la section *** Settings *** si nécessaire, mais souvent le nom du fichier suffit s'il est bien choisi.

*** Settings ***
Name    Tests d'Authentification Détaillés
Documentation    Cette suite couvre tous les scénarios d'authentification.

L'objectif est que, en regardant la liste des suites dans un rapport d'exécution, on puisse immédiatement comprendre quelles parties de l'application ont été testées.

Nommer les cas de test (Test Cases)

Le nom d'un cas de test est crucial car il décrit le scénario spécifique que le test valide. Il doit être formulé comme une affirmation ou une description concise de ce qui est testé et du résultat attendu. Robot Framework utilise nativement les espaces dans les noms de cas de test, ce qui permet une grande lisibilité, proche du langage naturel.

Style descriptif et orienté comportement : Essayez de nommer vos tests pour qu'ils décrivent le comportement attendu ou la règle métier vérifiée. Pensez à la structure "Etant donné (Given) - Lorsque (When) - Alors (Then)" du BDD (Behavior-Driven Development), même si vous ne l'appliquez pas formellement. Par exemple :

• Un Utilisateur Valide Devrait Pouvoir Se Connecter Avec Succès
• La Recherche D'un Produit Existant Devrait Afficher Les Bons Résultats
• Tenter De Créer Un Compte Avec Un Email Déjà Utilisé Devrait Afficher Un Message D'erreur

Utilisez des verbes d'action : Les noms de tests bénéficient souvent de l'utilisation de verbes clairs qui indiquent l'action principale ou la vérification. Par exemple, "Vérifier", "Valider", "Créer", "Supprimer", "Afficher".

Cohérence dans la structure : Si vous avez plusieurs tests pour une même fonctionnalité, essayez de maintenir une structure de nommage cohérente. Par exemple :

*** Test Cases ***
Connexion Utilisateur - Identifiants Valides
Connexion Utilisateur - Identifiants Invalides - Mot De Passe Erroné
Connexion Utilisateur - Identifiants Invalides - Email Inconnu
Connexion Utilisateur - Champ Email Vide

Un bon nom de cas de test permet, en cas d'échec, de comprendre immédiatement quel aspect de la fonctionnalité a échoué sans même avoir à lire le détail des étapes.

Nommer les mots-clés utilisateurs (User Keywords)

Les keywords utilisateurs sont au coeur de la réutilisabilité et de la lisibilité dans Robot Framework. Leurs noms doivent refléter l'action ou la séquence d'actions qu'ils encapsulent. Comme pour les cas de test, les espaces sont permis et encouragés pour une meilleure lisibilité. L'objectif est de créer une sorte de langage spécifique à votre domaine (DSL - Domain Specific Language) pour décrire les interactions avec votre application.

Action-orienté : Le nom d'un keyword doit clairement indiquer ce qu'il fait. Utilisez un verbe d'action au début. Par exemple :

• Ouvrir Le Navigateur Et Naviguer Vers La Page De Connexion
• Remplir Le Formulaire De Connexion Avec Les Identifiants
• Vérifier Que Le Message De Bienvenue Est Affiché
• Ajouter Un Produit Au Panier

Niveau d'abstraction approprié : Le nom doit correspondre au niveau d'abstraction du keyword. Un keyword de haut niveau pourrait être Effectuer Une Commande Complète De Produit, tandis qu'un keyword de plus bas niveau pourrait être Cliquer Sur Le Bouton "Ajouter Au Panier".

Eviter les noms trop génériques ou trop spécifiques : Un nom comme Cliquer est trop générique. Cliquer Sur Le Bouton OK De La Pop Up De Confirmation De Suppression Du Compte XYZ est trop spécifique et peu réutilisable. Trouvez le juste milieu.

Cohérence : Utilisez les mêmes verbes et la même terminologie pour des actions similaires à travers vos keywords. Si vous utilisez "Valider" pour les assertions dans un keyword, utilisez-le aussi dans les autres. Robot Framework gère bien les espaces et la capitalisation, ce qui donne un aspect très naturel :

*** Keywords ***
Se Connecter En Tant Que Administrateur
    [Arguments]    ${username}    ${password}
    Input Text     id:username_field    ${username}
    Input Text     id:password_field    ${password}
    Click Button   id:login_button

Nommer les variables

Le nommage des variables est tout aussi important pour la compréhension du code. Les variables stockent des données qui sont utilisées et potentiellement modifiées au cours de l'exécution des tests. Un nom de variable clair indique la nature et le but de la donnée qu'elle contient.

Conventions pour les types de variables :

• Variables scalaires (${NOM_VARIABLE}) : Utilisées pour des valeurs uniques (chaînes, nombres, booléens). Les noms sont traditionnellement en majuscules avec des underscores (SNAKE_UPPER_CASE), surtout pour les variables globales ou de suite. Pour les variables locales à un test ou un keyword, le camelCase (${maVariableLocale}) ou PascalCase (${MaVariableLocale}) est aussi parfois utilisé, bien que ${MA_VARIABLE_LOCALE} reste courant pour la cohérence.
• Variables de liste (@{NOM_LISTE}) : Utilisées pour des séquences d'éléments. Les noms doivent souvent être au pluriel pour indiquer qu'il s'agit d'une collection. La convention UPPER_SNAKE_CASE est également fréquente : @{PRODUITS_ATTENDUS}, @{NOMS_UTILISATEURS_TEST}.
• Variables de dictionnaire (&{NOM_DICTIONNAIRE}) : Utilisées pour des paires clé-valeur. Mêmes conventions de nommage que pour les scalaires et listes : &{CONFIG_UTILISATEUR}, &{DONNEES_PRODUIT}.

Descriptif et spécifique : Le nom doit décrire le contenu. ${URL_DE_CONNEXION} est meilleur que ${URL}. @{NOMS_PRODUITS_VALIDES} est plus clair que @{LISTE_NP}.

*** Variables ***
${URL_BASE}                 https://monapplication.com
${NAVIGATEUR_PAR_DEFAUT}    Chrome
@{UTILISATEURS_ADMINS}      admin1    admin2
&{CREDS_UTILISATEUR_TEST}
...    username=testuser
...    password=P4ssw0rd!

Portée de la variable : Si une variable a une portée limitée (par exemple, définie et utilisée uniquement dans un keyword spécifique), son nom peut être plus court si le contexte est clair. Cependant, pour les variables définies dans la section *** Variables *** d'un fichier ou passées en argument, la clarté est primordiale car elles peuvent être utilisées à plusieurs endroits.

En résumé, un nommage soigné est un investissement initial qui se rembourse largement en termes de temps gagné lors de la lecture, du débogage et de la maintenance de vos tests Robot Framework. C'est une des pierres angulaires d'un projet d'automatisation réussi.