Exemple 1 : Utilisation des keywords intégrés (BuiltIn) - `Log`, `Should Be Equal`

Apprenez à utiliser les keywords BuiltIn `Log` et `Should Be Equal` de Robot Framework à travers des exemples pratiques pour le logging et les assertions de base.

Les indispensables `BuiltIn` : `Log` et `Should Be Equal` en action

La librairie `BuiltIn` de Robot Framework est votre première boîte à outils. Elle regorge de keywords essentiels qui sont disponibles sans aucune importation préalable. Parmi eux, `Log` et `Should Be Equal` (ainsi que ses variantes) sont parmi les plus fréquemment utilisés. Le premier sert à enregistrer des informations pendant l'exécution du test, ce qui est crucial pour le débogage et la traçabilité. Le second est fondamental pour réaliser des assertions, c'est-à-dire vérifier que le comportement de l'application testée correspond aux attentes.

Comprendre le fonctionnement et les options de ces deux keywords vous donnera une base solide pour écrire des tests informatifs et fiables. Nous allons explorer, à travers des exemples concrets, comment les utiliser efficacement pour logger des messages pertinents et pour valider des conditions dans vos scénarios de test.

Ces exemples visent à illustrer la simplicité et la puissance de ces commandes de base, qui, bien que simples, sont au coeur de nombreux tests automatisés.

Le keyword `Log` : votre allié pour la traçabilité et le débogage

Le keyword `Log` permet d'écrire un message dans le fichier journal (`log.html`) généré par Robot Framework après l'exécution des tests. Ces messages sont extrêmement utiles pour suivre le déroulement d'un test, afficher des valeurs de variables à des moments clés, ou fournir des informations contextuelles qui peuvent aider à diagnostiquer des échecs.

Syntaxe de base :

Log    message    [level]

`message` : La chaîne de caractères que vous souhaitez logger. Vous pouvez y inclure des variables.
`level` (optionnel) : Le niveau de log. Les niveaux courants sont `TRACE`, `DEBUG`, `INFO` (défaut), `WARN`, `ERROR`. Le niveau de log affiché dans le rapport dépend du seuil configuré lors de l'exécution des tests (option `--loglevel` en ligne de commande).

Exemple d'utilisation simple :

*** Variables ***
${NOM_UTILISATEUR}    CertiQuizz User

*** Test Cases ***
Exemple de Log Simple
    Log    Début du cas de test : Exemple de Log Simple
    ${ville}    Set Variable    Paris
    Log    L'utilisateur ${NOM_UTILISATEUR} est localisé à ${ville}.
    Log    Ceci est un message d'avertissement    level=WARN
    Log    Une erreur simulée est survenue    level=ERROR
    Log    Fin du cas de test.

Dans le fichier `log.html`, vous verrez ces messages apparaître, chacun avec son niveau. Les messages `WARN` et `ERROR` seront mis en évidence, facilitant leur repérage.

Le keyword `Log To Console` est similaire à `Log`, mais il écrit également le message directement dans la sortie standard (la console où vous exécutez les tests), ce qui peut être utile pour un retour immédiat pendant l'exécution.

*** Test Cases ***
Exemple de Log To Console
    Log To Console    Ce message s'affiche dans la console et dans le log.html
    ${compteur}    Set Variable    42
    Log To Console    Valeur actuelle du compteur : ${compteur}

Utiliser `Log` judicieusement peut grandement simplifier le processus de débogage. Lorsque vous investiguez un test qui échoue, les messages de log peuvent vous donner des indices précieux sur l'état de l'application ou des variables à différentes étapes.

Le keyword `Should Be Equal` et ses variantes : valider les attentes

Les assertions sont le coeur de tout test automatisé. Elles permettent de vérifier si le résultat obtenu par une action correspond au résultat attendu. Le keyword `Should Be Equal` est l'un des principaux outils d'assertion de la librairie `BuiltIn`. Il vérifie que deux valeurs sont égales. Si elles ne le sont pas, le keyword échoue et, par conséquent, le cas de test échoue (sauf si l'erreur est gérée).

Syntaxe de base :

Should Be Equal    item1    item2    [message]    [values=True/False]    [ignore_case=True/False]    [formatter=str/repr]

`item1`, `item2` : Les deux items à comparer.
`message` (optionnel) : Un message personnalisé à afficher si l'assertion échoue. C'est une bonne pratique de toujours fournir un message clair.
`values` (optionnel, défaut `True`) : Si `True`, compare les valeurs des items. Si `False`, compare les types des items.
`ignore_case` (optionnel, défaut `False` pour les chaînes) : Si `True`, la comparaison des chaînes ignore la casse.
`formatter` (optionnel, défaut `str`) : `str` ou `repr`. Contrôle comment les items sont formatés dans le message d'erreur.

Exemple d'utilisation :

*** Variables ***
${NOM_ATTENDU}       CertiQuizz
${CODE_STATUT_OK}    200

*** Test Cases ***
Exemple de Should Be Equal
    ${nom_actuel}    Set Variable    CertiQuizz
    Should Be Equal    ${nom_actuel}    ${NOM_ATTENDU}    Le nom actuel ne correspond pas au nom attendu.

    ${code_reponse}    Set Variable    200
    Should Be Equal As Integers    ${code_reponse}    ${CODE_STATUT_OK}    Le code de statut de la réponse est incorrect.
    # Should Be Equal As Integers est spécifique pour les nombres, évitant les erreurs de type string vs int.

    ${texte_obtenu}     Set Variable    Robot Framework Rocks!
    ${texte_attendu_casse_differente}    Set Variable    robot framework rocks!
    Should Be Equal    ${texte_obtenu}    ${texte_attendu_casse_differente}    Les textes devraient être égaux (casse ignorée).    ignore_case=True

    # Exemple d'échec
    ${valeur_incorrecte}    Set Variable    Autre Chose
    Run Keyword And Expect Error    AssertionError: 'Autre Chose' != 'CertiQuizz'    Should Be Equal    ${valeur_incorrecte}    ${NOM_ATTENDU}
    # La ligne ci-dessus est un exemple de test d'une condition d'échec attendue.

Robot Framework propose plusieurs variantes de `Should Be Equal` pour des comparaisons plus spécifiques :

`Should Be Equal As Strings` : Convertit les deux items en chaînes de caractères avant de les comparer. Utile lorsque vous voulez comparer des nombres et des chaînes qui représentent les mêmes nombres, par exemple `${nombre_en_chaine}` et `${nombre_entier}`.
`Should Be Equal As Integers` : Convertit les deux items en entiers avant de les comparer. Echoue si la conversion n'est pas possible.
`Should Be Equal As Numbers` : Convertit les deux items en nombres à virgule flottante avant de les comparer. Permet de spécifier une tolérance pour les comparaisons de flottants.

*** Test Cases ***
Exemple de variantes de Should Be Equal
    Should Be Equal As Strings    42    42    # Compare "42" et "42"
    Should Be Equal As Strings    42    ${42} # Compare "42" et la représentation en chaîne de l'entier 42

    ${prix1}    Set Variable    10.00
    ${prix2}    Set Variable    10.001
    # Should Be Equal As Numbers    ${prix1}    ${prix2}    # Ceci échouerait
    Should Be Equal As Numbers    ${prix1}    ${prix2}    precision=2  # Compare avec 2 décimales de précision (10.00 vs 10.00)

    # Comparaison de listes ou dictionnaires (se fait par valeur)
    @{liste1}    Create List    a    b    c
    @{liste2}    Create List    a    b    c
    Should Be Equal    ${liste1}    ${liste2}    Les listes devraient être identiques.

    &{dict1}    Create Dictionary    nom=Robot    version=5.0
    &{dict2}    Create Dictionary    version=5.0    nom=Robot
    Should Be Equal    ${dict1}    ${dict2}    Les dictionnaires devraient être identiques (l'ordre des clés n'importe pas).

Il existe également le pendant négatif, `Should Not Be Equal` (et ses variantes `Should Not Be Equal As Strings`, etc.), qui vérifie que deux items ne sont pas égaux.

Maîtriser `Log` pour la visibilité et `Should Be Equal` pour la validation est une étape cruciale. Ces keywords, bien que simples, sont la base de tests robustes et faciles à déboguer. Ils vous permettent de documenter le flux d'exécution de vos tests et de vérifier explicitement que les résultats obtenus sont conformes à vos attentes.

◄ Précédent Suivant ►

く