Pourquoi Robot Framework ?

La polyvalence

Les librairies "standard" fournies [3] par Robot Framework permettent de réaliser les multiples actions et vérifications nécessaires que pourrait faire un utilisateur pour tester un logiciel.

Les librairies standard permettent, entre autres de:

• manipuler des données de base comme les chaines de caractères, les listes ou les dictionnaires
• manipuler des fichiers, dont des fichiers XML
• manipuler des processus
• manipuler des dates
• faire des assertions, ou autrement dit, faire des vérifications sur tous ces objets
• prendre des captures d'écran
• utiliser le protocole Telnet

Voici un exemple de test dans lequel nous allons rechercher une chaîne de caractère dans un fichier et vérifier qu'elle est bien présente (part 1). Nous allons ensuite lancer un executable et vérifier qu'il s'est réellement bien exécuté :

*** Test Cases ***
Test Example
    # Part 1
    ${resultat_recherche}=    Grep File    mon_fichier.log    ${chaine_recherchee}
    Should contain    ${resultat_recherche}    ${chaine_recherchee}
    # Part 2
    Start process    mon_executable.exe    shell=true    alias=process
    ${result}=    Wait For Process    process    timeout=10s    on_timeout=kill
    Should Be Equal As Integers    ${result.rc}    0

L'adaptabilité

S'adapter au logiciel à tester

Les librairies "standard" permettent, comme nous l'avons vu, d'écrire des tests basiques. Cependant, cela peut paraître limité pour s'adapter à des contextes de test plus évolués. Robot Framework permet aussi d'utiliser des librairies tierces, codées en Python ou en Java. Ceci ouvre la porte à l'automatisation de nombreux logiciels puisqu'il suffit quasiment [4] qu'une librairie (type harnais de test) existe pour que Robot Framework soit capable de se "brancher" dessus et d'exécuter des tests.

On peut citer surement ce qui est la plus "célèbre" des librairies tierces, Selenium, qui permet d'automatiser les tests d'interface web.

Voici un exemple tiré de la documentation de Selenium. Nous allons ouvrir un navigateur sur le site mon-super-site.com, puis saisir notre login et notre mot de passe et enfin vérifier que nous arrivont bien à la page de "bienvenue".

*** Settings ***
Library           SeleniumLibrary

*** Variables ***
${LOGIN URL}      http://mon-super-site.com
${BROWSER}        Chrome

*** Test Cases ***
Valid Login
    Open Browser    ${LOGIN URL}    ${BROWSER}
    Title Should Be    Login Page
    Input Text    username_field    ${username}
    Input Text    password_field    ${password}
    Click Button    login_button
    Title Should Be    Welcome Page
    [Teardown]    Close Browser

S'adapter aux testeurs

Nous avons vu comment Robot Framework pouvait s'adapter au logiciel à tester et au contexte de test. Il faut savoir que Robot Framework peut aussi adapter sa manière d'écrire les tests. En effet, il est possible d'écrire les tests de plusieurs manières différentes, soit en KDT [5] (ce que nous avons vu jusque ici dans les extraits de code) c'est à dire avec des instructions qui "collent" aux actions et vérifications que pourrait faire un utilisateur, soit en utilisant le langage Gherkin, couramment utilisé en BDD [6] [7].

*** Test Cases ***
Gherkin Test Example
    Given login page is open
    When valid username and password are inserted
    and credentials are submitted
    Then welcome page should be open

Cela signifie que l'on peut d'abord partir sur une démarche ATDD, moins contraignante et évoluer ensuite vers une démarche BDD. Cette liberté de choix est aussi intéressante car un même outil peut convenir à plusieurs "populations" différentes au sein d'une même entreprise (Développeur, Testeur, Métier...).

L'évolutivité

Enfin, je voulais parler d'un aspect, qui je pense est moins connu, mais qui est extrêmement puissant. Il est possible de modifier le cœur du fonctionnement de Robot Framework grâce à son API et à un système de plugin [8].

Sans trop rentrer dans les détails techniques - car il est vrai que cet aspect est plus technique - il est possible d'intercepter et de modifier l'exécution et la manière dont Robot Framework réalise ses actions et exécute les tests. Cela offre une multitude de possibilité et pour n'en citer qu'une, je donnerais l'exemple du plugin robotframework-testrail qui permet de pousser les résultats d'exécutions des tests Robot Framework dans l'outil de gestion de tests TestRail.

Dans l'exemple ci-dessous, on a ajouté un tag avec le numéro du test qui correspond à celui du test dans TestRail (test_case_id=1234). En utilisant l'API de Robot Framework, le plugin est capable de récupérer facilement ce numéro et le résultat du test puis de le publier dans TestRail :

*** Test Cases ***
Valid Login
    [Tags]  test_case_id=1234
    Given login page is open
    When valid username and password are inserted
    and credentials are submitted
    Then welcome page should be open