Concevoir son premier test case

Définir le scénario : la fondation de votre test

La première étape, et sans doute la plus cruciale, dans la création d'un test case automatisé est la définition claire et précise de ce que vous souhaitez vérifier. Un scénario bien défini est la clé d'un test pertinent et efficace. Demandez-vous : quelle fonctionnalité spécifique de l'application est-ce que je veux tester ? Quel comportement utilisateur suis-je en train de simuler ? Et, surtout, quel est le résultat attendu qui confirmera que la fonctionnalité opère correctement ?

Pour illustrer, imaginons que nous voulons tester la fonctionnalité de connexion d'un site web. Le scénario pourrait être : "Un utilisateur avec des identifiants valides tente de se connecter au site". A partir de là, nous décomposons ce scénario en actions plus petites et en vérifications. L'objectif est de traduire une exigence métier ou une spécification fonctionnelle en une série d'étapes logiques que le robot pourra exécuter. Pensez à la granularité : un test case doit idéalement vérifier une chose spécifique. S'il devient trop complexe, envisagez de le diviser en plusieurs tests plus petits et plus ciblés.

Il est essentiel de considérer les préconditions (l'état du système avant le test, par exemple, un utilisateur doit déjà être créé) et les postconditions (l'état attendu du système après le test, par exemple, l'utilisateur est redirigé vers son tableau de bord). Une bonne pratique consiste à documenter ces scénarios de manière concise, par exemple en utilisant une approche inspirée du BDD (Behavior-Driven Development) avec des phrases simples décrivant l'action et le résultat attendu. Cela facilitera la compréhension et la maintenance future de vos tests.

Ecrire les étapes avec des keywords : le langage de Robot Framework

Une fois votre scénario clairement défini, il est temps de le traduire en instructions compréhensibles par Robot Framework. C'est là qu'interviennent les "keywords" (mots-clés). Dans Robot Framework, un test case est essentiellement une séquence de keywords, chacun représentant une action ou une vérification. Cette approche rend les tests lisibles, même pour des personnes n'ayant pas de fortes compétences en programmation.

La syntaxe de Robot Framework s'inspire du style Gherkin (utilisé dans des outils comme Cucumber) avec sa structure `Given-When-Then` (Etant donné - Quand - Alors), bien que Robot Framework soit plus flexible. Vous n'êtes pas contraint d'utiliser ces termes, mais l'idée est similaire : préparer l'environnement, effectuer une action, et vérifier le résultat. Chaque ligne de votre test case commencera généralement par un keyword suivi de ses arguments, séparés par au moins deux espaces.

Prenons notre exemple de connexion :

*** Test Cases ***
Connexion Utilisateur Valide
    Ouvrir le Navigateur Sur La Page De Connexion    # Keyword utilisateur ou de librairie
    Entrer le Nom Utilisateur    utilisateur_test    # Keyword avec un argument
    Entrer le Mot De Passe       motdepasse123
    Cliquer Sur Le Bouton Connexion
    Vérifier Que L'Utilisateur Est Connecté
    [Teardown]    Fermer Le Navigateur               # Action exécutée à la fin du test

Dans cet exemple, `Ouvrir le Navigateur Sur La Page De Connexion`, `Entrer le Nom Utilisateur`, etc., sont des keywords. Certains peuvent provenir de librairies intégrées ou externes (comme SeleniumLibrary pour le web), d'autres peuvent être des keywords que vous créez vous-même (User Keywords) pour encapsuler des séquences d'actions réutilisables. L'important est la lisibilité et la modularité. Chaque keyword doit représenter une étape logique et compréhensible du scénario.

Les assertions : valider les résultats attendus avec précision

Un test ne sert à rien s'il ne vérifie pas explicitement que le résultat obtenu correspond au résultat attendu. C'est le rôle des assertions. Une assertion est une instruction qui évalue une condition ; si la condition est fausse, le test échoue.

Robot Framework fournit une multitude de keywords d'assertion, principalement via sa librairie `BuiltIn`. Les plus courants incluent :

• Should Be Equal / Should Be Equal As Strings / Should Be Equal As Numbers : Vérifie si deux valeurs sont égales.
• Should Contain : Vérifie si une chaîne de caractères en contient une autre, ou si une liste contient un élément.
• Should Be True / Should Be False : Vérifie une condition booléenne.
• Should Not Be Empty : Vérifie qu'une variable ou une liste n'est pas vide.

De plus, les librairies spécifiques, comme `SeleniumLibrary` pour les tests web, apportent leurs propres keywords d'assertion. Par exemple :

• Page Should Contain : Vérifie la présence d'un texte sur la page actuelle.
• Element Should Be Visible : Vérifie qu'un élément web spécifique est visible.
• Title Should Be : Vérifie le titre de la page.

Reprenons notre exemple de connexion. Le keyword `Vérifier Que L'Utilisateur Est Connecté` pourrait être un User Keyword qui encapsule plusieurs assertions :

*** Keywords ***
Vérifier Que L'Utilisateur Est Connecté
    Page Should Contain    Bienvenue, utilisateur_test
    Location Should Be     ${URL_TABLEAU_DE_BORD}    # ${URL_TABLEAU_DE_BORD} est une variable
    Element Should Be Visible    id=logout_button

L'utilisation judicieuse des assertions est ce qui donne sa valeur à un test automatisé. Elles doivent être précises et couvrir les aspects critiques du comportement attendu. Un test sans assertion ou avec des assertions vagues n'est pas un test fiable. L'objectif est de s'assurer que chaque étape du scénario produit le résultat escompté, garantissant ainsi la robustesse de votre application.