Robot Framework Guide de

l'utilisateur
Version 3.0.4
Copyright © 2008-2015 Nokia Networks
Copyright © 2016- Robot Framework Foundation
Sous licence Creative Commons Attribution 3.0 Unported licence

Table des matières

 1 Pour commencer
o 1.1 Introduction
o 1.2 Copyright et licence
o 1.3 Instructions d'installation
o 1.4 Démonstrations
 2 Création de données de test
o 2.1 Syntaxe des données de test
o 2.2 Création de cas de test
o 2.3 Création de suites de tests
o 2.4 Utilisation des bibliothèques de tests
o 2.5 Variables
o 2.6 Création de mots-clés utilisateur
o 2.7 Fichiers de ressources et variables
o 2.8 Fonctions avancées
 3 Exécution des cas de test
o 3.1 Utilisation de base
o 3.2 Exécution du test
o 3.3 Résultats du post-traitement
o 3.4 Configuration de l'exécution
o 3.5 sorties créées
 4 Extension du cadre du robot
o 4.1 Créer des bibliothèques de tests
o 4.2 Interface de bibliothèque distante
o 4.3 Interface auditeur
o 4.4 Extension du pot du cadre robot
 5 outils de support
o 5.1 Outil de documentation de la bibliothèque (Libdoc)
o 5.2 Outil de documentation des données de test (Testdoc)
o 5.3 Outil de nettoyage des données de test (Tidy)
o 5.4 Outils externes
 6 annexes
o 6.1 Tous les paramètres disponibles dans les données de test
o 6.2 Toutes les options de ligne de commande
o 6.3 Modèles de données de test
o 6.4 Formatage de la documentation
 o 6.5 Format de l'heure
o 6.6 Arguments booléens
o 6.7 API interne

1 Pour commencer
 1.1 Introduction
 1.2 Copyright et licence
 1.3 Instructions d'installation
 1.4 Démonstrations

1.1 Introduction
Robot Framework est une infrastructure d'automatisation des tests basée sur des
mots clés et extensible, basée sur Python, destinée aux tests d'acceptation de bout
en bout et au développement basé sur les tests d'acceptation (ATDD). Il peut être
utilisé pour tester des applications distribuées et hétérogènes, où la vérification
nécessite de toucher plusieurs technologies et interfaces.

Le cadre comprend un écosystème riche constitué de diverses bibliothèques de tests

génériques et d’outils développés en tant que projets distincts. Pour plus
d'informations sur Robot Framework et l'écosystème, voir http://robotframework.org .

Robot Framework est un logiciel open source publié sous la licence Apache 2.0 . Son
développement est sponsorisé par la Robot Framework Foundation .

 1.1.1 Pourquoi Robot Framework?

 1.1.2 Architecture de haut niveau
 1.1.3 Captures d'écran
 1.1.4 Obtenir plus d'informations
o Pages du projet
o Listes de diffusion

1.1.1 Pourquoi Robot Framework?

 Permet une syntaxe tabulaire facile à utiliser pour créer des scénarios
de test de manière uniforme.
 Permet de créer des mots clés de niveau supérieur réutilisables à partir des mots
clés existants.
 Fournit des rapports de résultats faciles à lire et des journaux au format HTML.
 Est indépendant de la plate-forme et de l'application.
 Fournit une API de bibliothèque simple pour créer des bibliothèques de tests
personnalisées pouvant être implémentées de manière native avec Python ou
Java.
  Fournit une interface de ligne de commande et des fichiers de sortie basés sur
XML pour l'intégration dans l'infrastructure de construction existante
(systèmes d'intégration continue).
 Fournit la prise en charge de Selenium pour les tests Web, les tests
d'interface graphique Java, les processus en cours, Telnet, SSH, etc.
 Prend en charge la création de cas de test basés sur des données .
 Prise en charge intégrée des variables , en particulier pour les tests dans
différents environnements.
 Fournit un marquage pour classer et sélectionner des scénarios de test à exécuter.
 Permet une intégration facile avec le contrôle de code source: les suites de
tests ne sont que des fichiers et des répertoires qui peuvent être versionnés
avec le code de production.
 Fournit cas-test et test de la suite configuration -level et désassemblage.
 L'architecture modulaire prend en charge la création de tests, même pour des
applications comportant plusieurs interfaces différentes.

1.1.2 Architecture de haut niveau

Robot Framework est un cadre générique, indépendant des applications et des
technologies. Son architecture très modulaire est illustrée dans le diagramme ci-
dessous.

Architecture du cadre robot

Les données de test sont dans un format tabulaire simple et facile à éditer. Lorsque
Robot Framework est démarré, il traite les données de test, exécute des scénarios de
test et génère des journaux et des rapports. L'infrastructure principale ne connaît
rien de la cible testée et l'interaction avec celle-ci est gérée par les bibliothèques de
tests . Les bibliothèques peuvent soit utiliser directement les interfaces
d’application, soit utiliser des outils de test de niveau inférieur en tant que pilotes.
1.1.3 Captures d'écran
Les captures d'écran suivantes montrent des exemples de données de test et
des rapports et journaux créés .

Dossier de test

Rapports et journaux

1.1.4 Obtenir plus d'informations

Pages du projet
Le numéro un pour trouver plus d'informations sur Robot Framework et le riche
écosystème qui l'entoure est http://robotframework.org . Robot Framework est hébergé
sur GitHub .

Listes de diffusion
Il existe plusieurs listes de diffusion Robot Framework où demander et rechercher
plus d'informations. Les archives de la liste de diffusion sont ouvertes à tous (y
compris aux moteurs de recherche) et tout le monde peut également rejoindre ces
listes librement. Cependant, seuls les membres de la liste peuvent envoyer des
messages et, pour éviter le spam, les nouveaux utilisateurs sont modérés, ce qui
signifie que le premier message peut prendre un peu de temps. N'ayez pas peur
d'envoyer des questions aux listes de diffusion, mais souvenez-vous de comment
poser des questions de manière intelligente .

robotsframework-users
Discussion générale sur tous les problèmes liés à Robot Framework. Des
questions et des problèmes peuvent être envoyés à cette liste. Utilisé aussi
pour le partage d'informations pour tous les utilisateurs.
robotframework-annonce
Une liste de diffusion réservée aux annonces où seuls les modérateurs
peuvent envoyer des messages. Toutes les annonces sont également
envoyées à la liste de diffusion robotframework-users, il n'est donc pas
nécessaire de joindre les deux listes.
robotframework-devel
Discussion sur le développement du cadre robotique.

1.2 Copyright et licence

Robot Framework est un logiciel open source fourni sous la licence Apache 2.0 . La
documentation de Robot Framework, telle que ce Guide de l'utilisateur, utilise
la licence Creative Commons Attribution 3.0 Unported . La plupart des bibliothèques et
des outils de l'écosystème plus large autour du cadre sont également open source,
mais ils peuvent utiliser des licences différentes.

La notice de copyright complète de Robot Framework est incluse ci-dessous:

Copyright 2008-2015 Nokia Networks
Copyright 2016- Robot Framework Foundation

Licence sous la licence Apache, version 2.0 (la "licence");

vous ne pouvez utiliser ce fichier que conformément à la licence.
Vous pouvez obtenir une copie de la licence à

http://www.apache.org/licenses/LICENSE-2.0

Sauf si requis par la loi applicable ou accepté par écrit, le logiciel

 distribué sous la licence est distribué sur une base "tel quel",
SANS GARANTIE OU CONDITION D'AUCUNE SORTE, expresse ou implicite.
Voir la licence pour la langue spécifique régissant les autorisations
et
limitations en vertu de la licence.

1.3 Instructions d'installation

Ces instructions couvrent l'installation et la désinstallation de Robot Framework et
de ses conditions préalables sur différents systèmes d'exploitation. Si vous avez
déjà installé pip , il suffit de lancer:
pip installer robotframework
 1.3.1 Introduction
 1.3.2 Conditions préalables
o Python 2 vs Python 3
o Installation de Python
o Installation de Jython
o Installation d'IronPython
o Installation PyPy
o Configuration de PATH
o Définition de https_proxy
 1.3.3 Installation avec pip
o Installation de pip pour Python
o Installation de pip pour Jython
o Installation de pip pour IronPython
o Installation de pip pour PyPy
o En utilisant pip
 1.3.4 Installation à partir de la source
o Obtenir le code source
o Installation
 1.3.5 Distribution JAR autonome
 1.3.6 Installation manuelle
 1.3.7 Vérification de l'installation
o Où les fichiers sont installés
 1.3.8 Désinstallation
 1.3.9 Mise à niveau
 1.3.10 Exécution du framework de robot
o Utilisation de scripts robot et rebot
o Exécution du module robot installé
o Exécution du répertoire du robot installé
 1.3.11 Utilisation d'environnements virtuels

1.3.1 Introduction
Robot Framework est implémenté avec Python et prend également en
charge Jython (JVM), IronPython (.NET) et PyPy . Avant d'installer le framework,
une condition préalable évidente est d'installer au moins un de ces interprètes.
Les différentes manières d'installer Robot Framework lui-même sont énumérées ci-
dessous et expliquées plus en détail dans les sections suivantes.

Installation avec pip

L'utilisation de pip est la méthode recommandée pour installer Robot

Framework. En tant que gestionnaire de paquets Python standard, il est
inclus dans les dernières versions de Python, Jython et IronPython. Si vous
avez déjà pip disponible, vous pouvez simplement exécuter:
pip installer robotframework
Installation à partir de la source
Cette approche fonctionne indépendamment du système d'exploitation et de
l'interpréteur Python utilisé. Vous pouvez obtenir le code source en
téléchargeant une distribution source à partir de PyPI et en l'extrayant ou en
clonant le référentiel GitHub .
Distribution JAR autonome
Si l'exécution de tests avec Jython est suffisante, l'approche la plus simple
consiste à télécharger la version autonome de robotframework- <version>
.jar depuis Maven Central . La distribution JAR contient à la fois Jython et
Robot Framework et ne nécessite donc que l' installation de Java .
Installation manuelle
Si vous avez des besoins particuliers et que rien ne fonctionne, vous pouvez
toujours effectuer une installation manuelle personnalisée.

Remarque

Avant Robot Framework 3.0, il existait également des programmes d'installation Windows
distincts pour les versions Python 32 bits et 64 bits. Étant donné que Python 2.7.9 et les
versions plus récentes contiennent pip sur Windows et que Python 3 aurait eu besoin de deux
programmes d’installation supplémentaires, il a été décidé que les programmes d’ installation
Windows ne seraient plus créés . L'approche d'installation recommandée également sous
Windows utilise pip .

1.3.2 Conditions préalables

Robot Framework est pris en charge sur Python (Python 2 et Python
3), Jython (JVM) et IronPython (.NET) et PyPy . L'interpréteur que vous souhaitez
utiliser doit être installé avant d'installer le framework lui-même.

Le type d'interpréteur à utiliser dépend des bibliothèques de test et de

l'environnement de test nécessaires. Certaines bibliothèques utilisent des outils ou
des modules qui ne fonctionnent qu'avec Python, tandis que d'autres peuvent
utiliser des outils Java nécessitant Jython ou nécessitant .NET et ainsi
IronPython. Il existe également de nombreux outils et bibliothèques qui
fonctionnent bien avec tous les interprètes.
Si vous n'avez pas de besoins particuliers ou si vous souhaitez simplement essayer
le framework, il est recommandé d'utiliser Python. C'est l'implémentation la plus
mature, beaucoup plus rapide que Jython ou IronPython (en particulier le temps de
démarrage est plus rapide), et également disponible sur la plupart des systèmes
d'exploitation de type UNIX. Une autre bonne alternative consiste à utiliser
la distribution JAR autonome qui ne contient que Java comme condition préalable.

Python 2 vs Python 3
Python 2 et Python 3 sont pour la plupart le même langage, mais ils ne sont pas
totalement compatibles les uns avec les autres. La principale différence est que
dans Python 3, toutes les chaînes sont en Unicode alors qu'en Python 2, les chaînes
sont des octets par défaut, mais il existe également plusieurs autres modifications
incompatibles avec les versions précédentes. La dernière version de Python 2 est
Python 2.7, sortie en 2010 et sera supportée jusqu'en 2020. Voir Est-ce que je dois
utiliser Python 2 ou 3? pour plus d'informations sur les différences, la version à
utiliser, comment écrire du code compatible avec les deux versions, etc.

Robot Framework 3.0 est la première version de Robot Framework à prendre en

charge Python 3. Il prend également en charge Python 2, et le plan est de continuer
à prendre en charge Python 2 tant que Python 2 est officiellement pris en
charge. Nous espérons que les auteurs des bibliothèques et des outils de
l’écosystème Robot Framework élargi commenceront également à examiner le
support de Python 3 maintenant que l’infrastructure principale le supporte.

Installation de Python
Sur la plupart des systèmes UNIX, tels que Linux et OS X, Python est installé par
défaut. Si vous êtes sous Windows ou si vous devez installer Python vous-même,
vous pouvez commencer par http://python.org . Vous pouvez y télécharger un
programme d'installation approprié et obtenir plus d'informations sur le processus
d'installation et sur Python en général.

Robot Framework 3.0 prend en charge Python 2.6, 2.7, 3.3 et versions ultérieures,
mais il est prévu de supprimer la prise en charge de Python 2.6 dans RF 3.1 . Si vous
devez utiliser d'anciennes versions, Robot Framework 2.5-2.8 prend en charge
Python 2.5 et Robot Framework 2.0-2.1 prennent en charge Python 2.3 et 2.4.

Après avoir installé Python, vous souhaiterez probablement toujours

configurer PATH pour que Python lui-même, ainsi que le robot et les scripts runner
de rebot , soient exécutables sur la ligne de commande.

Pointe
Les derniers installateurs Windows Python permettent de définir PATH dans le cadre de
l'installation. Ceci est désactivé par défaut, mais Add python.exe to Pathpeut être activé à
l' Customize Pythonécran.

Installation de Jython
L'utilisation de bibliothèques de tests implémentées avec Java ou utilisant des outils
Java en interne nécessite l'exécution de Robot Framework sur Jython , qui nécessite
à son tour Java Runtime Environment (JRE) ou Java Development Kit
(JDK). L'installation de l'une de ces distributions Java est hors de portée de ces
instructions, mais vous pouvez trouver plus d'informations, par exemple,
sur http://java.com .

L'installation de Jython est une procédure assez simple, et la première étape

consiste à obtenir un programme d'installation à partir de http://jython.org . Le
programme d'installation est un package JAR exécutable que vous pouvez exécuter
à partir de la ligne de commande java -jar jython_installer-
<version>.jar. Selon la configuration du système, il peut également être possible
de double-cliquer sur le programme d'installation.

Robot Framework 3.0 prend en charge Jython 2.7 qui nécessite Java 7 ou version
ultérieure. Si des versions plus anciennes de Jython ou de Java sont nécessaires,
Robot Framework 2.5-2.8 prend en charge Jython 2.5 (requiert Java 5 ou version
ultérieure) et Robot Framework 2.0-2.1 prend en charge Jython 2.2.

Après avoir installé Jython, vous souhaiterez probablement configurer PATH pour
que Jython soit lui-même, ainsi que le robot et les scripts runner de rebot exécutables
sur la ligne de commande.

Installation d'IronPython
IronPython permet d'exécuter Robot Framework sur la plate - forme .NET et
d'interagir avec C # et d'autres langages et API .NET. Seul IronPython 2.7 est pris
en charge.

Lors de l'utilisation d'IronPython, une dépendance supplémentaire consiste à

installer la version preview de elementtree module 1.2.7. Ceci est nécessaire car
le module elementtree distribué avec IronPython est cassé . Vous pouvez installer
le package en téléchargeant la distribution source, en le décompressant et en
exécutant ipy setup.py install à l'invite de commande du répertoire créé.

Après avoir installé IronPython, vous voulez probablement encore

configurer PATH pour faire IronPython lui - même ainsi que
les robots et rebot scripts runner exécutables sur la ligne de commande.
Installation PyPy
PyPy est une implémentation alternative du langage Python avec les versions
compatibles Python 2 et Python 3 disponibles. Son principal avantage sur
l'implémentation Python standard est qu'il peut être plus rapide et utiliser moins de
mémoire, mais cela dépend du contexte et de la manière dont il est utilisé. Si la
vitesse d'exécution est importante, au moins tester PyPY est probablement une
bonne idée.

L'installation de PyPy est une procédure simple et vous pouvez trouver les deux
programmes d'installation et les instructions d'installation sur http://pypy.org . Après
l'installation, vous souhaiterez probablement configurer PATH pour rendre PyPy
lui-même, ainsi que le robot et les scripts runner de rebot exécutables sur la ligne de
commande.

Configuration de PATH
La variable d'environnement PATH répertorie les emplacements où sont recherchées
les commandes exécutées dans un système. Pour faciliter l'utilisation de Robot
Framework à partir de l'invite de commandes, il est recommandé d'ajouter les
emplacements où les scripts runner sont installés dans PATH . Il est également souvent
utile d’avoir l’interpréteur lui-même dans PATH pour le rendre facile à exécuter.

Lors de l'utilisation de Python sur des machines de type UNIX, Python lui-même et
les scripts installés devraient être automatiquement intégrés dans PATH et ne
nécessiter aucune action supplémentaire. Sous Windows et avec d'autres
interpréteurs, le PATH doit être configuré séparément.

Pointe

Les derniers installateurs Windows Python permettent de définir PATH dans le cadre de
l'installation. Ceci est désactivé par défaut, mais Add python.exe to Pathpeut être activé à
l' Customize Pythonécran. Il ajoutera le répertoire d'installation Python et
le répertoire Scripts au PATH .

Quels répertoires ajouter à PATH

Les répertoires que vous devez ajouter au PATH dépendent de l'interpréteur et du

système d'exploitation. Le premier emplacement est le répertoire d'installation de
l'interpréteur (par exemple C: \ Python27 ) et l'autre est l'emplacement où les
scripts sont installés avec cet interpréteur. Python et IronPython installent les
scripts dans le répertoire Scripts sous le répertoire d'installation sous Windows (par
exemple C: \ Python27 \ Scripts ) et Jython utilise le répertoire bin quel que soit le
système d'exploitation (par exemple, C: \ jython2.7.0 \ bin ).
Notez que les répertoires Scripts et bin ne peuvent pas être créés dans le cadre de
l'installation de l'interpréteur, mais uniquement lorsque Robot Framework ou un
autre module tiers est installé.

Définition de PATH sous Windows

Sous Windows, vous pouvez configurer PATH en suivant les étapes ci-
dessous. Notez que les noms de paramètres exacts peuvent être différents sur
différentes versions de Windows, mais l'approche de base doit toujours être la
même.

1. Ouvrir Control Panel > System > Advanced > Environment Variables. Il y
a User variableset System variables, et la différence entre eux, c'est que les
variables utilisateur n'affectent que les utilisateurs actuels, alors que les
variables système affectent tous les utilisateurs.
2. Pour éditer une valeur PATH existante , sélectionnez Editet
ajoutez ;<InstallationDir>;<ScriptsDir>à la fin de la valeur (par
exemple ;C:\Python27;C:\Python27\Scripts). Notez que les points-virgules
( ;) sont importants car ils séparent les différentes entrées. Pour ajouter une
nouvelle valeur PATH , sélectionnez Newet définissez le nom et la valeur, cette
fois sans le point-virgule en tête.
3. Quittez la boîte de dialogue Okpour enregistrer les modifications.
4. Démarrez une nouvelle invite de commande pour que les modifications
prennent effet.

Notez que si plusieurs versions de Python sont installées, le robot exécuté ou

le script runner de rebot utilisera toujours celui qui se trouve
en premier dans PATH, quelle que soit la version de Python sur laquelle ce script est
installé. Pour éviter cela, vous pouvez toujours exécuter le module de robot installé
directement comme .C:\Python27\python.exe -m robot

Notez également que vous ne devez pas ajouter de guillemets autour des répertoires
que vous ajoutez dans PATH (par exemple "C:\Python27\Scripts"). Les
citations peuvent causer des problèmes avec les programmes Python et elles ne sont pas
nécessaires dans ce contexte même si le chemin du répertoire contient des espaces.

Définition de PATH sur des systèmes de type UNIX

Sur les systèmes de type UNIX, vous devez généralement modifier un fichier de
configuration spécifique au système ou à l'utilisateur. Le fichier à modifier et la
manière dont il dépend, et vous devez consulter la documentation de votre système
d'exploitation pour plus de détails.

Définition de https_proxy
Si vous installez avec pip et êtes derrière un proxy, vous devez définir la variable
d'environnement https_proxy . Il est nécessaire à la fois lors de l'installation de pip
lui-même et lors de son utilisation pour installer Robot Framework et d'autres
packages Python.

Comment définir le https_proxy dépend du système d'exploitation de la même

manière que la configuration de PATH . La valeur de cette variable doit être une URL
du proxy, par exemple http://10.0.0.42:8080.

1.3.3 Installation avec pip

Le gestionnaire de paquets Python standard est pip , mais il existe également
d'autres alternatives telles que Buildout et easy_install . Ces instructions ne couvrent
que l'utilisation de pip, mais d'autres gestionnaires de paquets devraient également
pouvoir installer Robot Framework.

Les dernières versions de Python, Jython, IronPython et PyPy contiennent des

paquets groupés. Les versions qui les contiennent et la manière de les activer sont
présentées dans les sections ci-dessous. Consultez les pages du projet pip si vous
souhaitez obtenir les dernières instructions d'installation si vous devez l'installer.

Remarque

Seul Robot Framework 2.7 et plus récent peut être installé à l'aide de pip. Si vous avez besoin
d'une ancienne version, vous devez utiliser d'autres méthodes d'installation.

Installation de pip pour Python

A partir de Python 2.7.9, l'installateur Windows standard par défaut installe et
active pip. En supposant que vous ayez également configuré PATH et que vous
ayez éventuellement défini https_proxy, vous pouvez l'exécuter pip install
robotframeworkimmédiatement après l'installation de Python. Avec Python 3.4 et
plus récent, pip fait officiellement partie de l'interpréteur et devrait être
automatiquement disponible.

En dehors de Windows et avec les anciennes versions de Python, vous devez

installer vous-même pip. Vous pouvez le faire en utilisant des gestionnaires de
paquetages système comme Apt ou Yum sous Linux, mais vous pouvez toujours
utiliser les instructions d'installation manuelle trouvées dans les pages du
projet pip .

Si vous avez plusieurs versions de Python avec pip installé, la version utilisée
lorsque la commande pip est exécutée dépend du premier pip dans la variable
PATH . Une alternative consiste à exécuter directement le module pip en utilisant la
version Python sélectionnée:
python -m pip installe robotframework
python3 -m pip installe robotframework

Installation de pip pour Jython

Jython 2.7 contient le paquet pip, mais il doit être activé avant de l'utiliser en
exécutant la commande suivante:
jython -m assurepip

Jython installe son pip dans le répertoire <JythonInstallation> / bin . Est-ce que
courir pip install robotframeworkréellement l'utilise ou peut-être une autre
version de pip dépend de quel pip est le premier dans le PATH . Une alternative
consiste à exécuter directement le module pip en utilisant Jython:
jython -m pip installe robotframework

Installation de pip pour IronPython

IronPython contient pip intégré à partir de la version 2.7.5 . De même que pour
Jython, il faut d'abord l'activer:
ipy -X: Frames -m assurepip

Notez qu'avec l' -X:Framesoption de ligne de commande IronPython, vous

devez activer et utiliser pip.

IronPython installe pip dans le répertoire <IronPythonInstallation> / Scripts . Est-

ce que courir pip install robotframeworkréellement l'utilise ou peut-être une autre
version de pip dépend de quel pip est le premier dans le PATH . Une alternative
consiste à exécuter directement le module pip en utilisant IronPython:
ipy -X: images -m pip install robotframework

Les versions d'IronPython antérieures à 2.7.5 ne prennent pas officiellement en

charge pip.

Installation de pip pour PyPy

PyPy contient également le paquet pip. Il n'est pas activé par défaut, mais il peut
être activé de la même manière qu'avec les autres interpréteurs:
pypy -m assurepip
pypy3 -m assurepip

Si vous avez plusieurs versions de Python avec pip installé, la version utilisée
lorsque la commande pip est exécutée dépend du premier pip dans la variable
PATH . Une autre solution consiste à exécuter directement le module pip
en utilisant PyPy:
pypy -m pip
pypy3-m pip

En utilisant pip
Une fois que vous avez installé pip et que vous avez défini https_proxy si vous êtes
derrière un proxy, l'utilisation de pip sur la ligne de commande est très simple. La
manière la plus simple d’utiliser pip est de le laisser rechercher et télécharger les
paquets qu’il installe à partir de l’ index Python Package Index (PyPI) , mais il peut
également installer les paquets téléchargés séparément à partir de PyPI. Les
utilisations les plus courantes sont indiquées ci-dessous et la documentation
de pip contient plus d'informations et d'exemples.
# Installer la dernière version (ne met pas à jour)
pip installer robotframework

# Mettre à jour vers la dernière version

installation de pip --upgrade robotframework

# Installer une version spécifique

pip install robotframework == 2 .9.2

# Installer le paquet téléchargé séparément (aucune connexion réseau

nécessaire)
pip installer robotframework-3.0.tar.gz

# Installer le dernier code (éventuellement inédit) directement depuis

GitHub
pip install git + https: //github.com/robotframework/RobotFramework.git

# Désinstaller
pip désinstallation robotframework

Notez que pip 1.4 et versions ultérieures installent uniquement des versions stables
par défaut. Si vous souhaitez installer un candidat alpha, beta ou release, vous
devez soit spécifier la version explicitement, soit utiliser l' option --pre :
# Install 3.0 beta 1
install pip robotframework == 3 .0b1

# Mettre à jour vers la dernière version même s'il s'agit d'une pré-version
pip install --pre --upgrade robotframework

Notez que sous Windows, par défaut, ne recrée pas les scripts de
démarrage robot.bat et rebot.bat si la même version de Robot Framework est installée
plusieurs fois avec la même version de Python. Cela pose principalement des
problèmes lors de l' utilisation d'environnements virtuels , mais il faut également
prendre en compte les installations personnalisées à l'aide de pip. Une solution de
contournement si vous utilisez l' option --no-cache-dir comme pip install --no-
cache-dir robotframework . Il est également possible d'ignorer les scripts de
démarrage et d'utiliser plutôt les commandes python -m robot et python -
m robot.rebot .

1.3.4 Installation à partir de la source

Cette méthode d'installation peut être utilisée sur n'importe quel système
d'exploitation avec l'un des interprètes pris en charge. L'installation à partir de la
source peut paraître un peu effrayante, mais la procédure est plutôt simple.

Obtenir le code source

Vous obtenez généralement la source en téléchargeant une distribution source
à partir de PyPI en tant que .tar.gzpackage. Une fois que vous avez téléchargé le
package, vous devez l'extraire quelque part et, par conséquent, vous obtenez un
répertoire nommé robotframework-<version>. Le répertoire contient le code source
et un script setup.py nécessaire à son installation.

Une autre approche pour obtenir le code source est le référentiel GitHub du projet de
clonage directement. Par défaut, vous obtiendrez le dernier code, mais vous pourrez
facilement passer à différentes versions publiées ou à d’autres balises.

Installation
Robot Framework est installé à partir du source en utilisant
le script standard setup.py de Python . Le script se trouve dans le répertoire
contenant les sources et vous pouvez l'exécuter à partir de la ligne de commande en
utilisant l'un des interpréteurs pris en charge:
python setup.py installer
jython setup.py installer
ipy setup.py installer
pypy setup.py installer

Le script setup.py accepte plusieurs arguments permettant, par exemple,

l'installation dans un emplacement autre que celui par défaut qui ne nécessite pas de
droits d'administration. Il est également utilisé pour créer différents packages de
distribution. Exécuter python setup.py --helppour plus de détails.

1.3.5 Distribution JAR autonome

Robot Framework est également distribué en tant qu'archive Java autonome
contenant à la fois Jython et Robot Framework et ne nécessite qu'une dépendance
de Java . C'est un moyen facile d'obtenir tout dans un seul paquet qui ne nécessite
aucune installation, mais présente l'inconvénient de ne pas fonctionner avec
l' interpréteur Python normal .
Le paquet s'appelle robotframework- <version> .jar et il est disponible sur
le central Maven . Après avoir téléchargé le package, vous pouvez exécuter des tests
avec:
java -jar robotframework-3.0.jar mytests.robot
java -jar robotframework-3.0.jar --variable name: valeur mytests.robot

Si vous souhaitez post-traiter les sorties à l' aide de Rebot ou utiliser d'autres outils de
support intégrés , vous devez donner le nom de la
commande rebot , libdoc , testdoc ou tidy en premier argument du fichier JAR:
java -jar robotframework-3.0.jar rebot output.xml
java -jar robotframework-3.0.jar liste libdoc MyLibrary

Pour plus d'informations sur les différentes commandes, exécutez le JAR sans
arguments.

Outre la bibliothèque standard Python et les modules Robot Framework, les

versions JAR autonomes à partir de la version 2.9.2 contiennent également la
dépendance PyYAML nécessaire au traitement des fichiers de variables yaml.

1.3.6 Installation manuelle

Si vous ne souhaitez utiliser aucune méthode automatique d'installation de Robot
Framework, vous pouvez toujours l'installer manuellement en procédant comme
suit:

1. Obtenez le code source. Tout le code est dans un répertoire (un paquet en
Python) appelé robot . Si vous disposez d'une distribution source ou d'une
vérification du contrôle de version, vous pouvez la trouver dans
le répertoire src , mais vous pouvez également l'obtenir à partir d'une
installation antérieure.
2. Copiez le code source où vous voulez.
3. Décidez comment exécuter les tests .

1.3.7 Vérification de l'installation

Après une installation réussie, vous devriez pouvoir exécuter les scripts
runner créés avec l' option --version et obtenir à la fois les versions Robot
Framework et interpréteur:
$ robot --version
Framework Robot 3 .0 ( Python 2 .7.10 sur Linux2 )

$ rebot --version
Rebot 3 .0 ( Python 2 .7.10 sur Linux2 )
Si l'exécution des scripts runner échoue avec un message indiquant que la
commande n'est pas trouvée ou reconnue, une première étape est de vérifier
la configuration PATH . Si cela ne vous aide pas, il est conseillé de relire les sections
pertinentes de ces instructions avant de chercher de l'aide sur Internet ou de
demander de l'aide sur la liste de diffusion des utilisateurs de robotframework ou
ailleurs.

Où les fichiers sont installés

Lorsqu'un programme d'installation automatique est utilisé, le code source de
Robot Framework est copié dans un répertoire contenant des modules Python
externes. Sur les systèmes d'exploitation de type UNIX où Python est pré-installé,
l'emplacement de ce répertoire varie. Si vous avez installé l'interpréteur vous-
même, il s'agit normalement des packages Lib / site sous le répertoire d'installation
de l'interpréteur, par exemple, C: \ Python27 \ Lib \ site-packages . Le code réel du
Framework de robot se trouve dans un répertoire nommé robot .

Les scripts runner de Robot Framework sont créés et copiés dans un autre
emplacement spécifique à la plate-forme. Lorsque vous utilisez Python sur des
systèmes de type UNIX, ils vont normalement dans / usr / bin ou / usr / local /
bin . Sous Windows et avec Jython et IronPython, les scripts se trouvent
généralement dans le répertoire Scripts ou bin du répertoire d'installation de
l'interpréteur.

1.3.8 Désinstallation
La méthode la plus simple pour désinstaller Robot Framework consiste à
utiliser pip :
pip désinstallation robotframework

Une fonctionnalité intéressante de pip est qu’il peut désinstaller des packages
même s’ils sont installés depuis la source. Si vous n'avez pas de pip disponible ou
si vous avez effectué une installation manuelle sur un emplacement personnalisé,
vous devez rechercher où les fichiers sont installés et les supprimer manuellement.

Si vous avez défini PATH ou configuré l'environnement, vous devez annuler ces
modifications séparément.

1.3.9 Mise à niveau

Si vous utilisez pip , la mise à niveau vers une nouvelle version nécessite de
spécifier explicitement la version ou d'utiliser l' option --upgrade . Si vous
effectuez une mise à niveau vers une version de prévisualisation, l' option --
pre est également requise.
# Mise à niveau vers la dernière version stable. C'est la méthode la plus
courante.
installation de pip --upgrade robotframework

# Mise à niveau vers la dernière version même si ce serait une version

préliminaire.
pip install --upgrade --pre robotframework

# Mettre à niveau vers la version spécifiée.

pip install robotframework == 2 .9.2

Lors de l'utilisation de pip, il désinstalle automatiquement les versions précédentes

avant l'installation. Si vous effectuez l' installation à partir de la source , vous devriez
pouvoir installer en toute sécurité sur une installation existante. Si vous rencontrez
des problèmes, la désinstallation avant l'installation peut vous aider.

Lors de la mise à niveau de Robot Framework, la nouvelle version contient

toujours des modifications incompatibles avec les versions antérieures qui affectent
les tests ou les infrastructures de test existants. De telles modifications sont très
rares dans les versions mineures comme 2.8.7 ou 2.9.2, mais plus courantes dans
les versions majeures comme 2.9 et 3.0. Les modifications incompatibles et les
fonctionnalités obsolètes sont expliquées dans les notes de publication, et il est
conseillé de les étudier, en particulier lors de la mise à niveau vers une nouvelle
version majeure.

1.3.10 Exécution du framework de robot

Utilisation de scripts robot et rebot
A partir de Robot Framework 3.0, les tests sont exécutés à l'aide
du script du robot et les résultats sont post-traités avec le script rebot :
robot tests.robot
rebot output.xml

Ces deux scripts sont installés dans le cadre de l'installation normale et peuvent être
exécutés directement à partir de la ligne de commande si PATH est défini
correctement. Ils sont implémentés en utilisant Python sauf sur Windows où ils sont
des fichiers batch.

Les anciennes versions de Robot Framework n'ont pas le script du robot et

le script rebot est installé uniquement avec Python. Au lieu de cela, ils ont des
scripts spécifiques à l'interpréteur pybot , jybot et ipybot pour l'exécution des tests
et jyrebot et ipyrebot pour les sorties de post-traitement. Ces scripts fonctionnent
toujours, mais ils seront dépréciés et supprimés à l'avenir.

Exécution du module robot installé

Une autre façon d'exécuter des tests consiste à exécuter directement
le module robot installé ou son sous-module robot.run à l' aide de l' option de
ligne de commande -m de Python . Ceci est particulièrement utile si Robot
Framework est utilisé avec plusieurs versions de Python:
robot python -m tests.robot
python3 -m robot.run tests.robot
robot jython -m tests.robot
/ opt / jython / robot jython -m tests.robot

La prise en charge de l' approche robot python -m est une nouvelle fonctionnalité
de Robot Framework 3.0, mais les anciennes versions prennent en charge python -
m robot.run . Ce dernier doit également être utilisé avec Python 2.6.

Les sorties de post-traitement utilisant la même approche fonctionnent également,

mais le module à exécuter est robot.rebot :
python -m robot.rebot output.xml

Exécution du répertoire du robot installé

Si vous savez où Robot Framework est installé, vous pouvez également
exécuter directement le répertoire du robot installé ou le fichier run.py :
chemin python / vers / robot / tests.robot
chemin jython / to / robot / run.py tests.robot

L'exécution du répertoire est une nouvelle fonctionnalité de Robot Framework 3.0,

mais les anciennes versions prennent en charge l'exécution du fichier robot /
run.py.

Les sorties de post-traitement utilisant le fichier robot / rebot.py fonctionnent de la

même manière:
chemin python / vers / robot / rebot.py output.xml

Exécuter Robot Framework de cette façon est particulièrement pratique si vous

avez effectué une installation manuelle .

1.3.11 Utilisation d'environnements virtuels

Les environnements virtuels Python permettent d'installer les packages Python dans
un emplacement isolé pour un système ou une application spécifique, plutôt que
d'installer tous les packages dans le même emplacement global. Les
environnements virtuels peuvent être créés à l'aide de l' outil virtualenv ou, à partir
de Python 3.3, à l'aide du module venv standard .
Robot Framework en général fonctionne bien avec les environnements virtuels. Le
seul problème est que lorsque vous utilisez pip sur Windows,
les scripts robot.bat et rebot.bat ne sont pas recréés par défaut. Cela signifie que
si Robot Framework est installé dans plusieurs environnements virtuels,
les scripts robot.bat et rebot.bat dans ces derniers font référence à l'installation de
Python dans le premier environnement virtuel. Une solution consiste à utiliser
l' option --no-cache-dir lors de l'installation. Sinon, les scripts de démarrage
peuvent être ignorés et les commandes python -mrobot et python -
m robot.rebot utilisées à la place.

1.4 Démonstrations
Plusieurs projets de démonstration introduisent Robot Framework et facilitent son
démarrage.

Guide de démarrage rapide

Présente les fonctionnalités les plus importantes de Robot Framework et agit
comme une démo exécutable.
Démonstration de Robot Framework
Exemples simples de cas de test. Montre également la création de
bibliothèques de tests personnalisées.
Démo de test Web
Montre comment créer des tests et des mots clés de niveau supérieur. Le
système testé est une simple page Web testée à l'aide de SeleniumLibrary .
Démo SwingLibrary
Démontrer l'utilisation de SwingLibrary pour tester des applications
d'interface graphique Java.
ATDD avec Robot Framework
Montre comment utiliser Robot Framework lorsque vous suivez le processus
ATDD (Acceptance Test Driven Development).

2 Création de données de test

 2.1 Syntaxe des données de test
 2.2 Création de cas de test
 2.3 Création de suites de tests
 2.4 Utilisation des bibliothèques de tests
 2.5 Variables
 2.6 Création de mots-clés utilisateur
 2.7 Fichiers de ressources et variables
 2.8 Fonctions avancées

2.1 Syntaxe des données de test

Cette section couvre la syntaxe globale des données de test de Robot
Framework. Les sections suivantes expliquent comment créer des scénarios de test,
des suites de tests, etc.

 2.1.1 Fichiers et répertoires

 2.1.2 Formats de fichiers pris en charge
o Format HTML
o Format TSV
o Format texte brut
o format reStructuredText
 2.1.3 Tableaux de données de test
 2.1.4 Règles pour l'analyse des données
o Données ignorées
o Manipulation d'espaces
o Échapper
o Division des données de test sur plusieurs lignes

2.1.1 Fichiers et répertoires

La structure hiérarchique pour organiser les cas de test est la suivante:

 Les cas de test sont créés dans des fichiers de cas de test .
 Un fichier de scénario de test crée automatiquement une suite de
tests contenant les scénarios de test dans ce fichier.
 Un répertoire contenant des fichiers de cas de test forme une suite de tests de
niveau supérieur. Un tel répertoire de suites de tests comporte des suites
créées à partir de fichiers de scénarios de test en tant que suites de sous-tests.
 Un répertoire de suites de tests peut également contenir d'autres répertoires
de suites de tests, et cette structure hiérarchique peut être aussi profondément
imbriquée que nécessaire.
 Les répertoires de la suite de tests peuvent avoir un fichier
d’initialisation spécial .

En plus de cela, il y a:

 Test des bibliothèques contenant les mots-clés de niveau inférieur.

 Fichiers de ressources contenant des variables et des mots - clés d'utilisateur
de niveau supérieur .
 Fichiers de variables permettant de créer des variables de manière plus flexible
que les fichiers de ressources.

2.1.2 Formats de fichiers pris en charge

Les données de test de la structure de robot sont définies sous forme de tableau, en
utilisant soit les formats HTML (Hypertext Markup Language), TSV (valeurs
séparées par des tabulations), texte brut ou reStructuredText (reST). Les détails de
ces formats, ainsi que les principaux avantages et problèmes associés, sont
expliqués dans les sections suivantes. Le format à utiliser dépend du contexte, mais
le format texte brut est recommandé s'il n'y a pas de besoins particuliers.

Robot Framework sélectionne un analyseur pour les données de test en fonction de

l'extension de fichier. L'extension n'est pas sensible à la casse et les extensions
reconnues sont .html , .htm et .xhtmlpour HTML, .tsv pour
TSV, .txt et .robot spécial pour le texte brut et .rst et .rest pour reStructuredText.

Différents modèles de données de test sont disponibles pour les formats HTML et
TSV afin de faciliter la rédaction de tests.

Remarque

L' extension spéciale .robot avec des fichiers texte brut est prise en charge à partir de Robot
Framework 2.7.6.

Format HTML
Les fichiers HTML prennent en charge le formatage et le texte libre autour des
tables. Cela permet d'ajouter des informations supplémentaires dans les fichiers de
cas de test et de créer des fichiers de cas de test qui ressemblent à des spécifications
de test formelles. Le principal problème avec le format HTML est que l'édition de
ces fichiers à l'aide d'éditeurs de texte normaux n'est pas si simple. Un autre
problème est que HTML ne fonctionne pas aussi bien avec les systèmes de contrôle
de version car les diffs résultant des modifications contiennent de la syntaxe HTML
en plus des modifications apportées aux données de test réelles.

Dans les fichiers HTML, les données de test sont définies dans des tableaux
distincts (voir l'exemple ci-dessous). Robot Framework reconnaît ces tables de
données de test en fonction du texte de leur première cellule. Tout ce qui est en
dehors des tables reconnues est ignoré.

Utiliser le format HTML

Réglage Valeur Valeur Valeur

Bibliothèque Système opérateur

Variable Valeur Valeur Valeur

$ {MESSAGE} Bonjour le monde!

 Cas de test action Argument Argument

Mon test [Documentation] Exemple de test

Bûche $ {MESSAGE}

Mon mot clé / tmp

Un autre test Devrait être égal $ {MESSAGE} Bonjour le monde!

Mot-clé action Argument Argument

Mon mot clé [Arguments] $ {path}

Répertoire devrait exister $ {path}

Modification des données de test

Les données de test dans les fichiers HTML peuvent être éditées avec n'importe
quel éditeur, mais un éditeur graphique, où vous pouvez voir les tables, est
recommandé. RIDE peut lire et écrire des fichiers HTML, mais malheureusement il
perd tout le formatage HTML ainsi que les données possibles en dehors des tables
de tests.

Codage et références d'entité

Les références d'entité HTML (par exemple &auml;) sont prises en charge. De plus,
tout codage peut être utilisé, en supposant qu'il soit spécifié dans le fichier de
données. Les fichiers HTML normaux doivent utiliser l'élément META comme
dans l'exemple ci-dessous:
<meta http-equiv = "Content-Type" content = "text / html; charset =
UTF-8">

Les fichiers XHTML doivent utiliser le préambule XML comme dans cet exemple:
<? xml version = "1.0" encoding = "Big5"?>

Si aucun codage n'est spécifié, Robot Framework utilise ISO-8859-1 par défaut.

Format TSV
Les fichiers TSV peuvent être édités dans des tableurs et, comme la syntaxe est si
simple, ils sont faciles à générer par programmation. Ils sont également assez
faciles à éditer en utilisant des éditeurs de texte normaux et ils fonctionnent bien
dans le contrôle de version, mais le format de texte brut est encore mieux adapté à ces
fins.
Le format TSV peut être utilisé dans les données de test de Robot Framework aux
mêmes fins que HTML. Dans un fichier TSV, toutes les données sont dans une
grande table. Les tables de données de test sont reconnues à partir d'un ou plusieurs
astérisques ( *), suivis d'un nom de table normal et d'un astérisque de fermeture
facultatif. Tout ce qui précède la première table reconnue est ignoré de la même
manière que les données externes aux tables dans les données HTML.

Utiliser le format TSV

*Réglage* *Valeur* *Valeur* *Valeur*

Bibliothèque Système opérateur

*Variable* *Valeur* *Valeur* *Valeur*

$ {MESSAGE} Bonjour le monde!

*Cas de test* *Action* *Argument* *Argument*

Mon test [Documentation] Exemple de test

Bûche $ {MESSAGE}

Mon mot clé / tmp

Un autre test Devrait être égal $ {MESSAGE} Bonjour le monde!

*Mot-clé* *Action* *Argument* *Argument*

Mon mot clé [Arguments] $ {path}

Répertoire devrait exister $ {path}

Modification des données de test

Vous pouvez créer et modifier des fichiers TSV dans n'importe quel tableur, tel que
Microsoft Excel. Sélectionnez le format séparé par des tabulations lorsque vous
enregistrez le fichier et n'oubliez pas de définir l'extension du fichier sur .tsv . Il est
également conseillé de désactiver toutes les corrections automatiques et de
configurer l’outil pour traiter toutes les valeurs du fichier en texte brut.
Les fichiers TSV sont relativement faciles à modifier avec n'importe quel éditeur de
texte, en particulier si l'éditeur prend en charge la séparation visuelle des onglets
des espaces. Le format TSV est également pris en charge par RIDE .

Robot Framework analyse les données TSV en divisant tout le contenu en lignes
puis en lignes en cellules sur la base des caractères tabulaires. Les tableurs
entourent parfois les cellules de guillemets (par exemple "my value") et Robot
Framework les supprime. Les guillemets possibles à l'intérieur des données sont
doublés (par exemple "my ""quoted"" value") et ceci est également géré
correctement. Si vous utilisez un tableur pour créer des données TSV, vous ne
devez pas faire attention à cela, mais si vous créez des données par programmation,
vous devez suivre les mêmes conventions que les feuilles de calcul.

Codage

Les fichiers TSV doivent toujours utiliser le codage UTF-8. Comme l'ASCII est un
sous-ensemble de UTF-8, le format ASCII simple est également supporté
naturellement.

Format texte brut

Le format texte brut est très facile à éditer avec n'importe quel éditeur de texte et
fonctionne très bien dans le contrôle de version. Grâce à ces avantages, il est
devenu le format de données le plus utilisé avec Robot Framework.

Le format texte brut est techniquement similaire au format TSV, mais le séparateur
entre les cellules est différent. Le format TSV utilise des onglets, mais dans le
format texte brut, vous pouvez utiliser deux ou plusieurs espaces ou un caractère de
canal entouré d'espaces ( | ).

Les tables de données de test doivent comporter un ou plusieurs astérisques avant leur
nom, de la même manière qu'au format TSV. Sinon, les astérisques et les espaces
possibles dans l'en-tête de la table sont ignorés, par exemple, *** Settings
***et *Settingsfonctionnent de la même manière. De même que dans le format
TSV, tout ce qui précède la première table est ignoré.

Dans les fichiers texte, les onglets sont automatiquement convertis en deux
espaces. Cela permet d'utiliser un seul onglet comme séparateur de la même
manière qu'au format TSV. Notez cependant que, dans le format texte brut,
plusieurs onglets sont considérés comme un seul séparateur alors que dans le
format TSV, chaque onglet serait un séparateur.

Format séparé par espace

Le nombre d'espaces utilisés comme séparateur peut varier, pour autant qu'il y ait
au moins deux espaces, et il est donc possible d'aligner correctement les
données. C'est un avantage évident par rapport à l'édition du format TSV dans un
éditeur de texte car avec TSV, l'alignement ne peut pas être contrôlé.
*** Paramètres ***
Système d' exploitation de bibliothèque

*** Variables ***

$ { MESSAGE } Bonjour tout le monde!

*** Cas de test ***

Mon test
[ Documentation ] Exemple de test
Log $ { MESSAGE }
Mon mot clé / tmp

Un autre test
Devrait être égal $ { MESSAGE } Bonjour tout le monde!

*** Mots clés ***

Mon mot clé
[ Arguments ] $ { path } Le
répertoire doit exister $ { path }

Parce que l'espace est utilisé comme séparateur, toutes les cellules vides doivent
être échappées avec une ${EMPTY}variable ou une barre oblique inverse
unique. Sinon, la gestion des espaces n'est pas différente de celle des autres données
de test, car les espaces de début, de fin et consécutifs doivent toujours être
échappés.

Pointe

Il est recommandé d'utiliser quatre espaces entre les mots-clés et les arguments.

Format séparé par tuyau et espace

Le plus gros problème du format délimité par des espaces est que la séparation
visuelle des mots-clés des arguments peut être délicate. C'est un problème en
particulier si les mots-clés prennent beaucoup d'arguments et / ou si les arguments
contiennent des espaces. Dans de tels cas, la variante délimitée par un tuyau ou un
espace peut mieux fonctionner car elle rend la limite de la cellule plus visible.
| * Réglage * | * Valeur * |
| Bibliothèque | Système d'exploitation |

| * Variable * | * Valeur * |
| $ { MESSAGE } | Bonjour le monde! |

| * Test Case * | * Action * | * Argument * |

| Mon test | [ Documentation ] | Exemple de test |
| | Journal | $ { MESSAGE } |
| | Mon mot clé | / tmp |
| Un autre test | Devrait être égal | $ { MESSAGE } | Bonjour le monde!
| * Mot-clé * |
| Mon mot clé | [ Arguments ] | $ { path }
| | Répertoire devrait exister | $ { path }

Un fichier de texte brut peut contenir des données de test dans des formats séparés
uniquement dans l'espace et dans l'espace et dans le canal, mais une seule ligne doit
toujours utiliser le même séparateur. Les lignes séparées par des tuyaux et des
espaces sont reconnues par le tube de début obligatoire, mais le tuyau à la fin de la
ligne est facultatif. Il doit toujours y avoir au moins un espace des deux côtés du
tuyau (sauf au début et à la fin), mais il n'est pas nécessaire d'aligner les tuyaux
autrement que si les données sont plus claires.

Il n'est pas nécessaire d'échapper aux cellules vides (autres que les cellules vides à
la fin ) lorsque vous utilisez le format séparé par canal et espace. La seule chose à
prendre en compte est que les éventuels canaux entourés d'espaces dans les données
de test doivent être échappés avec une barre oblique inverse:
| *** Cas de test *** | | | |
| Tuyau d'échappement | $ { nombre de fichiers } = | Exécuter la
commande | ls -1 * .txt \ | wc -l |
| | Devrait être égal | $ { nombre de fichiers } | 42 |

Edition et encodage

L'un des principaux avantages du format texte brut par rapport à HTML et à TSV
est qu'il est très facile de le modifier à l'aide d'éditeurs de texte normaux. De
nombreux éditeurs et IDE (au moins Eclipse, Emacs, Vim et TextMate) disposent
également de plug-ins prenant en charge la syntaxe en soulignant les données de
test de la structure Robot, ainsi que d'autres fonctionnalités telles que l'achèvement
des mots clés. Le format texte brut est également pris en charge par RIDE .

De même que pour les données de test TSV, les fichiers en texte brut doivent
toujours utiliser le codage UTF-8. En conséquence, les fichiers ASCII sont
également pris en charge.

Extensions reconnues

À partir de Robot Framework 2.7.6, il est possible d’enregistrer des fichiers de

données de test en texte brut en utilisant une extension .robot spéciale en plus de
l’ extension .txt normale . La nouvelle extension facilite la distinction entre les
fichiers de données de test et les autres fichiers en texte brut.

format reStructuredText
reStructuredText (reST) est une syntaxe de balisage en texte clair facile à lire qui est
couramment utilisée pour la documentation des projets Python (y compris Python
lui-même, ainsi que ce Guide de l'utilisateur). Les documents reST sont le plus
souvent compilés en HTML, mais d'autres formats de sortie sont également pris en
charge.

L'utilisation de reST avec Robot Framework vous permet de mélanger des

documents richement formatés et des données de test dans un format de texte
concis facile à utiliser à l'aide d'éditeurs de texte, d'outils de comparaison et de
systèmes de contrôle de source simples. En pratique, il combine de nombreux
avantages des formats texte et HTML.

Lorsque vous utilisez des fichiers reST avec Robot Framework, il existe deux
manières de définir les données de test. Vous pouvez soit utiliser des blocs de code et
définir des cas de test en utilisant le format texte brut ou bien vous pouvez utiliser
des tableaux exactement comme vous le feriez avec le format HTML .

Remarque

L'utilisation de fichiers reST avec Robot Framework nécessite l' installation

du module Python docutils .

Utiliser des blocs de code

Les documents reStructuredText peuvent contenir des exemples de code dans des
blocs de code. Lorsque ces documents sont compilés en HTML ou dans d'autres
formats, les blocs de code sont syntaxiques mis en évidence à l'aide
de Pygments . Dans la norme, les blocs de code reST sont démarrés à l'aide de
la codedirective, mais Sphinx utilise code-block ou à la sourcecodeplace. Le nom du
langage de programmation dans le bloc de code est donné en argument à la
directive. Par exemple, les blocs de code suivants contiennent des exemples Python
et Robot Framework, respectivement:
.. code :: python

def EXAMPLE_KEYWORD ():

print 'Bonjour, monde!

.. code :: robotframework

*** Cas de test ***

Exemple de test
Exemple de mot clé

Lorsque Robot Framework fichiers reStructuredText, parse il recherche d'abord

possible code, code-blockou des sourcecodeblocs contenant des données de test
Robot Framework. Si de tels blocs de code sont trouvés, les données qu'ils
contiennent sont écrites dans un fichier en mémoire et exécutées. Toutes les
données en dehors des blocs de code sont ignorées.
Les données de test dans les blocs de code doivent être définies au format texte
brut . Comme l'illustre l'exemple ci-dessous, les variantes séparées d'espace et de
tuyau sont prises en charge:
Exemple
-------

Ce texte est en dehors des blocs de code et est donc ignoré.

.. code :: robotframework

*** Paramètres ***

Système d' exploitation de bibliothèque

*** Variables ***

$ { MESSAGE } Bonjour tout le monde!

*** Cas de test ***

Mon test
[ Documentation ] Exemple de test
Log $ { MESSAGE }
Mon mot clé / tmp

Un autre test
Devrait être égal $ { MESSAGE } Bonjour tout le monde!

Aussi ce texte est en dehors des blocs de code et ignoré. Bloc supérieur
utilisé
le format de texte brut séparé par des espaces et le bloc ci-dessous
utilise le tube
variante séparée

.. code :: robotframework

| *** Mot-clé *** | | |

| Mon mot clé | [ Arguments ] | $ { path } |
| | Répertoire devrait exister | $ { path } |

Remarque

Echapper à la barre oblique inverse fonctionne normalement dans ce format. Aucun double
échappement n'est nécessaire comme lors de l'utilisation de tables reST.

Remarque

La prise en charge des données de test dans les blocs de code est une nouvelle fonctionnalité
de Robot Framework 2.8.2.

Utiliser des tables

Si un document reStructuredText ne contient aucun bloc de code avec les données

de la structure Robot, il est censé contenir les données des tables de la même
manière qu'au format HTML . Dans ce cas, Robot Framework compile le document
en HTML en mémoire et l'analyse exactement comme s'il analysait un fichier
HTML normal.
Robot Framework identifie les tables de données de test en fonction du texte dans la
première cellule et tout le contenu en dehors des types de table reconnus est
ignoré. Un exemple de chacune des quatre tables de données de test est présenté ci-
dessous en utilisant à la fois une syntaxe simple de table et de table de grille:
Exemple
-------

Ce texte est en dehors des tables et donc ignoré.

============ ==============================
Définition de la valeur de la valeur
============ ==============================
Système d'exploitation de bibliothèque
============ ==============================

============ ==============================
Valeur de valeur Valeur de valeur
============ ==============================
$ {MESSAGE} Bonjour tout le monde!
============ ==============================

============= ================== ==================== ======

Argument d'argument d'action de cas de test
============= ================== ==================== ======
Mon test [Documentation] Exemple de test
\ Log $ {MESSAGE}
\ Mon mot clé / tmp
\
Un autre test devrait être égal $ {MESSAGE} Bonjour tout le monde!
============= ================== ==================== ======

Aussi ce texte est en dehors des tables et ignoré. Les tableaux ci-dessus
sont créés
en utilisant la syntaxe de table simple et le tableau ci-dessous utilise la
table de grille
approche.

+ ------------- + ------------------------ + ---------- - + ------------ +

| Mot-clé | Action | Argument | Argument |
+ ------------- + ------------------------ + ---------- - + ------------ +
| Mon mot clé | [Arguments] | $ {path} | |
+ ------------- + ------------------------ + ---------- - + ------------ +
| | Répertoire devrait exister | $ {path} | |
+ ------------- + ------------------------ + ---------- - + ------------ +

Remarque

Les cellules vides dans la première colonne des tables simples doivent être
échappées. L'exemple ci-dessus utilise \ mais ..pourrait également être utilisé.

Remarque

Parce que le caractère barre oblique inverse est un caractère d'échappement dans reST, en
spécifiant une barre oblique inverse afin que Robot Framework puisse voir qu'il doit
s'échapper avec une autre barre oblique inverse, par exemple \\. Par exemple, un nouveau
caractère de ligne doit être écrit comme \\n. Étant donné que la barre oblique inverse est
utilisée pour échapper également dans les données de la structure de robot, la spécification
d'une barre oblique inverse littérale lors de l'utilisation de tables reST nécessite une double
évasion c:\\\\temp.

Générer des fichiers HTML basés sur des fichiers reST chaque fois que les tests
sont exécutés ajoute évidemment un peu de temps. S'il s'agit d'un problème, il peut
être judicieux de convertir les fichiers reST en HTML en utilisant des outils
externes séparément, et de laisser Robot Framework utiliser uniquement les fichiers
générés.

Edition et encodage

Les données de test dans les fichiers reStructuredText peuvent être modifiées avec
n'importe quel éditeur de texte, et de nombreux éditeurs fournissent également une
mise en évidence de la syntaxe automatique. Le format reST n'est cependant pas
pris en charge par RIDE .

Robot Framework nécessite que les fichiers reST contenant des caractères non-
ASCII soient enregistrés en utilisant le codage UTF-8.

Erreurs de syntaxe dans les fichiers sources reST

Si un document reStructuredText n'est pas syntaxiquement correct (un tableau mal

formé par exemple), l'analyse échouera et aucun cas de test ne sera trouvé dans ce
fichier. Lors de l'exécution d'un seul fichier reST, Robot Framework affichera
l'erreur sur la console. Lors de l'exécution d'un répertoire, ces erreurs d'analyse
seront généralement ignorées.

À partir de Robot Framework 2.9.2, les erreurs sous le niveau SEVEREsont ignorées
lors de l'exécution de tests pour éviter le bruit sur les directives non standard et
autres balises de ce type. Cela peut également cacher des erreurs réelles, mais elles
peuvent être vues lors du traitement normal des fichiers.

2.1.3 Tableaux de données de test

Les données de test sont structurées en quatre types de tableaux répertoriés ci-
dessous. Ces tables de données de test sont identifiées par la première cellule de la
table. Les noms de table sont reconnus Settings, Variables, Test
Caseset Keywords. La correspondance est insensible à la casse et les variantes
singulières comme Settinget Test Case sont acceptées.
 Différentes tables de données de test

Table Utilisé pour

Paramètres 1) Importation de bibliothèques de tests , de fichiers de ressources et de fichiers de

variables.
2) Définition des métadonnées pour les suites de tests et les cas de test .

Les Définir des variables pouvant être utilisées ailleurs dans les données de test.
variables

Cas de test Création de scénarios de test à partir des mots clés disponibles.

Mots clés Création de mots-clés utilisateur à partir de mots -clés de niveau inférieur existants

2.1.4 Règles pour l'analyse des données

Données ignorées
Lorsque Robot Framework analyse les données de test, il ignore:

 Toutes les tables qui ne commencent pas par un nom de table reconnu dans la
première cellule.
 Tout le reste sur la première rangée d'une table en dehors de la première
cellule.
 Toutes les données avant le premier tableau. Si le format de données autorise
les données entre les tables, cela est également ignoré.
 Toutes les lignes vides, ce qui signifie que ces types de lignes peuvent être
utilisés pour rendre les tableaux plus lisibles.
 Toutes les cellules vides à la fin des lignes, sauf si elles sont échappées .
 Toutes les barres obliques inverses simples ( \ ) si elles ne sont pas utilisées
pour s'échapper .
 Tous les caractères suivant le caractère dièse ( #), lorsqu'il s'agit du premier
caractère d'une cellule. Cela signifie que des marques de hachage peuvent
être utilisées pour saisir des commentaires dans les données de test.
 Tout le formatage dans les données de test HTML / reST.

Lorsque Robot Framework ignore certaines données, ces données ne sont pas
disponibles dans les rapports résultants et, de plus, la plupart des outils utilisés avec
Robot Framework les ignorent également. Pour ajouter des informations visibles
dans les sorties de la structure de robot, placez-les dans la documentation ou d'autres
métadonnées de scénarios de test ou de suites, ou connectez-les avec les mots-
clés BuiltIn Log ou Comment .

Manipulation d'espaces
Robot Framework gère les espaces comme ils le sont dans le code source HTML:

 Les nouvelles lignes, les retours chariot et les onglets sont convertis en
espaces.
 Les espaces de début et de fin dans toutes les cellules sont ignorés.
 Plusieurs espaces consécutifs sont regroupés dans un seul espace.

En plus de cela, les espaces insécables sont remplacés par des espaces
normaux. Ceci est fait pour éviter les erreurs difficiles à déboguer lorsqu'un espace
insécable est utilisé accidentellement au lieu d'un espace normal.

Si des espaces de début, de fin ou consécutifs sont nécessaires, ils doivent être
échappés . Les nouvelles lignes, retours chariot, des onglets et des espaces non-
rupture peuvent être créés en utilisant des séquences d'échappement \n , \r, \t, et
, \xA0respectivement.

Échapper
Le caractère d'échappement dans les données de test de Robot Framework est la
barre oblique inverse ( \ ) et les variables
intégrées supplémentaires ${EMPTY}et ${SPACE} peuvent souvent être utilisés pour
s'échapper. Différents mécanismes de fuite sont discutés dans les sections ci-
dessous.

Échapper des caractères spéciaux

Le caractère barre oblique inverse peut être utilisé pour échapper des caractères
spéciaux afin que leurs valeurs littérales soient utilisées.

Échapper des caractères spéciaux

Personnage Sens Exemples

\$ Le signe dollar ne démarre jamais une variable \${notvar}
scalaire .
\@ Au signe, ne commence jamais une variable de liste . \@{notvar}

\% Signe de pourcentage, ne démarre jamais une variable \%{notvar}

d'environnement .
\# Hash sign, ne commence jamais un commentaire . \# not comment

\= Signe égal, ne fait jamais partie de la syntaxe d'un not\=named

argument nommé .
\| Caractère de tuyau, pas un séparateur dans le format | Run | ps \| grep
séparé par un tuyau . xxx |
 Échapper des caractères spéciaux

Personnage Sens Exemples

\\ Caractère de barre oblique inverse, n'échappe jamais à c:\\temp, \\${var}
rien.

Former des séquences d'échappement

Le caractère barre oblique inverse permet également de créer des séquences

d'échappement spéciales reconnues comme des caractères qui seraient sinon
difficiles ou impossibles à créer dans les données de test.

Séquences d'échappement

Séquence Sens Exemples

\n Caractère de nouvelle ligne. first line\n2nd line

\r Caractère de retour de chariot text\rmore text

\t Caractère de tabulation. text\tmore text

\xhh Caractère avec valeur hexadécimale hh. null byte: \x00, ä: \xE4

\uhhhh Caractère avec valeur hexadécimale hhhh. snowman: \u2603

\Uhhhhhhhh Caractère avec valeur hexadécimale hhhhhhhh. love hotel: \U0001f3e9

Remarque

Toutes les chaînes créées dans les données de test, y compris des caractères tels que \x02,
sont Unicode et doivent être explicitement converties en chaînes d'octets si nécessaire. Cela
peut être fait, par exemple, en utilisant les mots-clés Convertir en octets ou Encoder les
chaînes en octets dans les bibliothèques BuiltIn et String , respectivement, ou avec
un code similaire à Python str(value)ou value.encode('UTF-8')en code.

Remarque

Si des valeurs hexadécimales invalides sont utilisées avec \x, \u ou \Us'échappent, le résultat
final est la valeur d'origine sans le caractère barre oblique inverse. Par exemple, \xAX(pas
hex) et \U00110000(trop grande valeur) résultent avec xAX et U00110000, respectivement. Ce
comportement peut changer à l'avenir, cependant.

Remarque

La variable intégrée ${\n} peut être utilisée si une terminaison de ligne dépendante du
système d'exploitation est nécessaire ( \r\nsous Windows et \nailleurs).

Remarque
Caractère d'espacement éventuel non échappé après le \nest ignoré. Cela signifie que two
lines\nhereet two lines\n heresont équivalents. La raison à cela est de permettre
l'encapsulation de lignes longues contenant des lignes nouvelles lors de l'utilisation du format
HTML, mais la même logique est également utilisée avec d'autres formats. Une exception à
cette règle est que le caractère d'espacement n'est pas ignoré dans la syntaxe de la variable
étendue .

Remarque

\x, \uet les \Uséquences d'échappement sont nouvelles dans Robot Framework 2.8.2.

Empêcher d'ignorer les cellules vides

Si des valeurs vides sont nécessaires comme arguments pour des mots-clés ou
autres, elles doivent souvent être échappées pour les empêcher d'être ignorées . Les
cellules de fin vide doivent être échappées quel que soit le format des données de
test, et lors de l'utilisation du format à espace séparé, toutes les valeurs vides doivent
être échappées.

Les cellules vides peuvent être échappées avec le caractère barre oblique inverse ou
avec la variable intégrée ${EMPTY} . Ce dernier est généralement recommandé car il
est plus facile à comprendre. Une exception à cette recommandation consiste à
échapper les cellules en retrait dans les boucles for avec une barre oblique inverse
lors de l'utilisation du format séparé par des espaces . Tous ces cas sont illustrés dans
les exemples suivants d'abord en HTML, puis dans le format de texte en clair:

Cas de test action Argument Argument Argument

Utiliser la barre Faire premier \

oblique inverse quelque argument
chose

Utiliser $ Faire premier $ {VIDE}

{EMPTY} quelque argument
chose

Non traînant vide Faire deuxième # Pas besoin

quelque argument d'échapper en HTML
chose

Pour la boucle :POUR $ {var} DANS @{VALEURS}

Bûche $ {var} # Pas de fuite

nécessaire ici non plus
*** Cas de test ***
Utiliser la barre oblique inverse
Faire quelque chose d' abord arg \
Utiliser $ { EMPTY }
Do Quelque chose d' abord arg $ { EMPTY } Non-vide à la fin

Faire quelque chose $ { EMPTY } second arg # S'échapper

nécessaire dans un format séparé par des espaces Pour la boucle
 : FOR $ { var } IN @ { VALEURS }
\ Log $ { var } # Échappement
nécessaire ici aussi

Empêcher d'ignorer les espaces

Étant donné que les espaces de début, de fin et consécutifs dans les cellules
sont ignorés , ils doivent être échappés s'ils sont nécessaires en tant qu'arguments de
mots-clés ou autres. De la même manière qu'en empêchant d'ignorer les cellules
vides, il est possible de le faire en utilisant le caractère barre oblique inverse ou en
utilisant une variable intégrée ${SPACE} .

Exemples d'espaces échappés

Échapper à la barre Échapper à ${SPACE} Remarques

oblique inverse

\ espace de tête ${SPACE}leading space

espace de fuite \ trailing space${SPACE} La barre oblique inverse doit être

après l'espace.

\ \ ${SPACE} La barre oblique inverse est

nécessaire des deux côtés.

\ \ espaces consecutive${SPACE * Utiliser la syntaxe de variable

consécutifs 3}spaces étendue .

Comme le montrent les exemples ci-dessus, l'utilisation de la ${SPACE}variable

facilite souvent la compréhension des données de test. Il est particulièrement utile
en combinaison avec la syntaxe de la variable étendue lorsque plusieurs espaces sont
nécessaires.

Division des données de test sur plusieurs lignes

S'il y a plus de données que facilement une ligne, il est possible d'utiliser des points
de suspension ( ...) pour continuer la ligne précédente. Dans les tables de tests et
les tables de mots-clés, les points de suspension doivent être précédés d'au moins
une cellule vide. Dans les tables de paramètres et de variables, il peut être placé
directement sous le paramètre ou le nom de la variable. Dans toutes les tables,
toutes les cellules vides avant les points de suspension sont ignorées.

De plus, les valeurs des paramètres qui ne prennent qu'une valeur (principalement
des documentations) peuvent être divisées en plusieurs colonnes. Ces valeurs seront
ensuite regroupées avec les espaces lors de l'analyse des données de test. À partir
de Robot Framework 2.7, les métadonnées de documentation et de suite de tests
divisées en plusieurs lignes seront regroupées avec les nouvelles lignes .
Toute la syntaxe décrite ci-dessus est illustrée dans les exemples suivants. Dans les
trois premières tables, les données de test n'ont pas été divisées et les trois suivantes
illustrent le nombre moins élevé de colonnes nécessaires après la division des
données en plusieurs lignes.

Données de test non divisées

Réglage Valeur Valeur Valeur Valeur Valeur Valeur

Balises par défaut tag-1 tag-2 tag-3 tag-4 tag-5 tag-6

Variable Valeur Valeur Valeur Valeur Valeur Valeur

@{LISTE} ce liste a assez beaucoup articles

Cas action Argument Ar Ar Arg Ar Ar Ar

de g g g g g
test

Exempl [Documentatio Documentati

e n] on pour ce
cas de test. \
N Cela peut
prendre
beaucoup de
temps ...

[Mots clés] t-1 t-2 t-3 t-4 t-5

Faire X un deux Trois quatr cinq six

e

$ {var} = Obtenez X 1 2 3 4 5 6

Données de test divisées en plusieurs lignes

Réglage Valeur Valeur Valeur

Balises par défaut tag-1 tag-2 tag-3

... tag-4 tag-5 tag-6

Variable Valeur Valeur Valeur

@{LISTE} ce liste a

... assez beaucoup articles

Cas de test action Argument Argument Argument

Exemple [Documentation] Documentation pour ça cas de test.

... Cela peut obtenir assez longue...

[Mots clés] t-1 t-2 t-3

... t-4 t-5

Faire X un deux Trois

... quatre cinq six

 Cas de test action Argument Argument Argument

$ {var} = Obtenez X 1 2

... 3 4

... 5 6

2.2 Création de cas de test

Cette section décrit la syntaxe globale du test élémentaire. L'organisation de
scénarios de test dans des suites de tests à l' aide de fichiers de scénarios de test et
de répertoires de suites de tests est présentée dans la section suivante.

 2.2.1 Syntaxe de test élémentaire

o Syntaxe de base
o Paramètres dans le tableau Test Case
o Paramètres de cas de test dans le tableau Paramètres
 2.2.2 Utilisation des arguments
o Arguments obligatoires
o Les valeurs par défaut
o Nombre variable d'arguments
o Arguments nommés
o Arguments de mots clés gratuits
o Arguments incorporés aux noms de mots clés
 2.2.3 Défaillances
o Lorsque le test échoue
o Messages d'erreur
 2.2.4 Nom du cas de test et documentation
 2.2.5 Marquage des cas de test
o Tags réservés
 2.2.6 Configuration du test et démontage
 2.2.7 Modèles de test
o Utilisation de base
o Modèles avec arguments incorporés
o Modèles avec pour boucles
 2.2.8 Différents styles de cas de test
o Style axé sur les mots clés
o Style axé sur les données
o Style axé sur le comportement

2.2.1 Syntaxe de test élémentaire

Syntaxe de base
Les scénarios de test sont construits dans des tables de scénarios de test à partir des
mots-clés disponibles. Les mots-clés peuvent être importés à partir
de bibliothèques de tests ou de fichiers de ressources ou créés dans la table de mots-
clés du fichier de scénario de test lui-même.

La première colonne de la table de cas de test contient des noms de cas de test. Un
scénario de test commence à partir de la ligne contenant quelque chose dans cette
colonne et continue jusqu'au nom du scénario de test suivant ou à la fin de la
table. C'est une erreur d'avoir quelque chose entre les en-têtes de table et le premier
test.

La deuxième colonne a normalement des noms de mots-clés. Une exception à cette

règle consiste à définir des variables à partir des valeurs de retour de mot-clé , lorsque la
deuxième colonne et éventuellement les colonnes suivantes contiennent des noms
de variable et qu'un nom de mot-clé est situé après elles. Dans les deux cas, les
colonnes après le nom du mot-clé contiennent des arguments possibles pour le mot-
clé spécifié.
*** Cas de test ***
Login valide
Ouvrir la page de connexion
Démo de saisie du nom d'utilisateur
Mode mot de passe d'entrée
Soumettre les informations d'identification
La page d'accueil devrait être ouverte

Définition des variables

Faire quelque chose premier argument deuxième argument
$ { value } = Obtenir de la valeur
Devrait être égal à $ { value } Valeur attendue

Remarque

Bien que les noms de cas de test puissent contenir n'importe quel caractère, l'utilisation ?et
surtout *ne sont généralement pas recommandés car ils sont considérés comme des caractères
génériques lors de la sélection des cas de test . Par exemple, si vous essayez d'exécuter
uniquement un test avec le nom Example * like --test 'Example *', vous exécuterez un
test commençant par Example .

Paramètres dans le tableau Test Case

Les cas de test peuvent également avoir leurs propres paramètres. Les noms de
paramètres sont toujours dans la deuxième colonne, où les mots-clés sont
normalement et leurs valeurs sont dans les colonnes suivantes. Les noms de
paramètres sont entourés de crochets pour les distinguer des mots-clés. Les
paramètres disponibles sont répertoriés ci-dessous et expliqués plus loin dans cette
section.

[Documentation]
Utilisé pour spécifier une documentation de scénario de test .
[Mots clés]
 Utilisé pour le marquage des cas de test .
[Setup] , [Teardown]
Spécifiez la configuration du test et le démontage .
[Modèle]
Spécifie le mot-clé du modèle à utiliser. Le test lui-même ne contiendra que
des données à utiliser comme arguments pour ce mot clé.
[Temps libre]
Utilisé pour définir un délai de test élémentaire .Les délais d'attente sont discutés
dans leur propre section.

Exemple de cas de test avec paramètres:

*** Cas de test ***
Test avec paramètres
[ Documentation ] Un autre test fictif
[ Tags ] propriétaire factice -johndoe
Journal Bonjour, monde!

Paramètres de cas de test dans le tableau Paramètres

Le tableau des paramètres peut comporter les paramètres suivants relatifs aux
scénarios de test. Ces paramètres sont principalement des valeurs par défaut pour
les paramètres spécifiques aux scénarios de test répertoriés précédemment.

Forcer les balises , les balises par défaut

Les valeurs forcées et par défaut des balises .
Configuration du test , test de résolution
Les valeurs par défaut pour la configuration du test et le démontage .
Modèle de test
Le mot-clé du modèle par défaut à utiliser.
Délai de test
La valeur par défaut pour le délai de test . Les délais d'attente sont discutés dans
leur propre section.

2.2.2 Utilisation des arguments

Les exemples précédents ont déjà démontré des mots-clés prenant des arguments
différents, et cette section traite de cette fonctionnalité importante de manière plus
approfondie. Comment implémenter réellement les mots - clés d'utilisateur et
de bibliothèque avec des arguments différents est décrite dans des sections distinctes.

Les mots-clés peuvent accepter zéro ou plusieurs arguments, et certains arguments

peuvent avoir des valeurs par défaut. Les arguments qu'un mot clé accepte
dépendent de son implémentation et le meilleur endroit pour rechercher ces
informations est la documentation du mot clé. Dans les exemples de cette section,
la documentation devrait être générée à l'aide de l' outil Libdoc , mais les mêmes
informations sont disponibles sur la documentation générée par des outils de
documentation génériques tels que javadoc .

Arguments obligatoires
La plupart des mots-clés ont un certain nombre d'arguments qui doivent toujours
être donnés. Dans la documentation du mot-clé, ceci est noté en spécifiant les noms
d'argument séparés par une virgule comme first, second, third. Les noms
d'argument n'ont en fait aucune importance dans ce cas, sauf qu'ils doivent
expliquer ce que fait l'argument, mais il est important d'avoir exactement le même
nombre d'arguments que ceux spécifiés dans la documentation. Utiliser trop peu ou
trop d'arguments entraînera une erreur.

Le test ci-dessous utilise des mots-clés Créer un répertoire et copier un fichier

à partir de la bibliothèque OperatingSystem . Leurs arguments sont spécifiés
comme pathet source, destination, ce qui signifie qu'ils prennent respectivement
un et deux arguments. Le dernier mot clé, No Operation from BuiltIn , ne prend
aucun argument.
*** Cas de test ***
Exemple
Créer un répertoire $ { TEMPDIR } / stuff
Copier le fichier $ { CURDIR } /file.txt $ { TEMPDIR } / stuff
Pas d'opération

Les valeurs par défaut

Les arguments ont souvent des valeurs par défaut qui peuvent être données ou
non. Dans la documentation, la valeur par défaut est généralement séparée du nom
de l'argument par un signe égal name=default value, mais avec les mots-clés
implémentés avec Java, il peut y avoir plusieurs implémentations du même mot-clé
avec des arguments différents. Il est possible que tous les arguments aient des
valeurs par défaut, mais il ne peut y avoir aucun argument de position après les
arguments avec des valeurs par défaut.

L'utilisation des valeurs par défaut est illustrée par l'exemple ci-dessous qui utilise
le mot clé Create File qui contient des arguments path, content=, encoding=UTF-
8. Essayer de l'utiliser sans aucun argument ou plus de trois arguments ne
fonctionnerait pas.
*** Cas de test ***
Exemple
Créer le fichier $ { TEMPDIR } /empty.txt
Créer le fichier $ { TEMPDIR } /utf-8.txt Hyvä esimerkki
Créer le fichier $ { TEMPDIR } /iso-8859-1.txt Hyvä esimerkki ISO-
8859-1
Nombre variable d'arguments
Il est également possible qu'un mot clé accepte un nombre quelconque
d'arguments. Ces soi-disant varargs peuvent être combinés avec des arguments et
des arguments obligatoires avec des valeurs par défaut, mais ils sont toujours
donnés après eux. Dans la documentation, ils ont un astérisque avant le nom de
l'argument comme *varargs.

Par exemple, les mots-clés Remove Files et Join Paths de

la bibliothèque OperatingSystem ont des arguments *pathset base, *parts,
respectivement. Le premier peut être utilisé avec un nombre quelconque
d’arguments, mais le second nécessite au moins un argument.
*** Cas de test ***
Exemple
Supprimer les fichiers $ { TEMPDIR } /f1.txt $ { TEMPDIR }
/f2.txt $ { TEMPDIR } /f3.txt
@ { chemins } = chemins de jointure $ { TEMPDIR } f1.txt
f2.txt f3.txt f4.txt

Arguments nommés
La syntaxe de l'argument nommé rend l'utilisation des arguments avec des valeurs
par défaut plus flexibles, et permet d'étiqueter explicitement ce que signifie une
valeur d'argument donnée. Les arguments nommés techniquement fonctionnent
exactement comme les arguments des mots-clés en Python.

Syntaxe de base

Il est possible de nommer un argument donné à un mot-clé en préfixant la valeur

avec le nom de l'argument comme arg=value. Ceci est particulièrement utile
lorsque plusieurs arguments ont des valeurs par défaut, car il est possible de ne
nommer que certains arguments et de laisser les autres utiliser leurs valeurs par
défaut. Par exemple, si un mot clé accepte des arguments arg1=a, arg2=b, arg3=c,
et qu'il est appelé avec un argument arg3=override, les
arguments arg1et arg2obtiennent leurs valeurs par défaut, mais arg3 obtiennent une
valeur override. Si cela semble compliqué, l' exemple des arguments nommés ci-
dessous le rend plus clair.

La syntaxe de l'argument nommé est à la fois sensible à la casse et à l'espace. Le

premier signifie que si vous avez un argument arg, vous devez l' utiliser
comme arg=value, et ni , Arg=valueni ARG=value œuvres. Ce dernier signifie que les
espaces ne sont pas autorisés avant le = signe, et les espaces possibles après sont
considérés comme faisant partie de la valeur donnée.

Lorsque la syntaxe de l'argument nommé est utilisée avec des mots - clés utilisateur ,
les noms d'argument doivent être donnés sans la ${}décoration. Par exemple, le
mot-clé utilisateur avec des arguments ${arg1}=first, ${arg2}=seconddoit être
utilisé comme arg2=override.

L'utilisation d'arguments de position normaux après des arguments nommés

comme, par exemple | Keyword | arg=value | positional |, ne fonctionne pas. À
partir de Robot Framework 2.8, cela provoque une erreur explicite. L'ordre relatif
des arguments nommés n'a pas d'importance.

Remarque

Avant Robot Framework 2.8, il était impossible de nommer des arguments sans valeur par
défaut.

Arguments nommés avec des variables

Il est possible d'utiliser des variables dans les deux noms d'argument nommés et les
valeurs. Si la valeur est une variable scalaire unique , elle est transmise au mot clé tel
quel. Cela permet d'utiliser des objets, et pas seulement des chaînes, comme valeurs
également lors de l'utilisation de la syntaxe de l'argument nommé. Par exemple,
l'appel d'un mot-clé comme arg=${object} , passera la variable ${object}au mot-
clé sans la convertir en chaîne.

Si des variables sont utilisées dans des noms d'argument nommés, les variables sont
résolues avant d'être comparées aux noms d'argument. Ceci est une nouvelle
fonctionnalité de Robot Framework 2.8.6.

La syntaxe de l'argument nommé nécessite que le signe égal soit écrit littéralement
dans l'appel du mot clé. Cela signifie que la variable seule ne peut jamais
déclencher la syntaxe de l'argument nommé, même si elle a une valeur
similaire foo=bar. Il est important de se rappeler, en particulier lors de l’enrobage
de mots-clés dans d’autres mots-clés. Si, par exemple, un mot - clé prend un nombre
variable d'arguments tels que @{args}et passe tous à un autre mot - clé en utilisant la
même @{args} syntaxe possible named=argsyntaxe utilisée dans le côté appelant
n'est pas reconnu. Ceci est illustré par l'exemple ci-dessous.
*** Cas de test ***
Exemple
Exécuter le shell du programme = True # Cela ne viendra pas comme
argument nommé pour exécuter le processus

*** Mots clés ***

Exécuter de programme
[ Arguments ] @ { args }
Exécuter le processus program.py @ { args } # Les arguments nommés
ne sont pas reconnus depuis l'intérieur de @ {args}

Si un mot clé doit accepter et transmettre des arguments nommés, il doit être
modifié pour accepter les arguments de mots clés gratuits . Voir les exemples de
kwargs pour une version de mot-clé wrapper pouvant transmettre à la fois les
arguments positionnels et nommés.

Échapper à la syntaxe des arguments nommés

La syntaxe de l'argument nommé est utilisée uniquement lorsque la partie de

l'argument avant le signe égal correspond à l'un des arguments du mot clé. Il est
possible qu'il y ait un argument de position avec une valeur littérale
comme foo=quux, et également un argument sans rapport avec le nom foo. Dans ce
cas, l'argument fooobtient la valeur de manière incorrecte quuxou, plus
probablement, une erreur de syntaxe.

Dans ces rares cas où il y a des correspondances accidentelles, il est possible

d'utiliser le caractère barre oblique inverse pour échapper à la
syntaxe foo\=quux. Maintenant, l'argument aura une valeur littérale foo=quux. Notez
que échapper n'est pas nécessaire s'il n'y a pas d'arguments avec nom foo, mais
parce que cela rend la situation plus explicite, cela peut néanmoins être une bonne
idée.

Où les arguments nommés sont supportés

Comme déjà expliqué, la syntaxe de l'argument nommé fonctionne avec des mots-
clés. En plus de cela, il fonctionne également lors de l' importation de bibliothèques .

Les arguments de dénomination sont pris en charge par les mots - clés utilisateur et
par la plupart des bibliothèques de tests . La seule exception concerne les
bibliothèques basées sur Java qui utilisent l' API de bibliothèque statique . La
documentation de la bibliothèque générée avec Libdoc a une note: la bibliothèque
prend-elle en charge les arguments nommés ou non.

Remarque

Avant Robot Framework 2.8, la syntaxe des arguments nommés ne fonctionnait pas avec les
bibliothèques de tests utilisant l' API de bibliothèque dynamique .

Exemple d'arguments nommés

L'exemple suivant illustre l'utilisation de la syntaxe des arguments nommés avec

des mots-clés de bibliothèque, des mots-clés utilisateur et lors de l'importation de
la bibliothèque de tests Telnet .
*** Paramètres ***
Invite Telnet de la bibliothèque = $ default_log_level = DEBUG

*** Cas de test ***

Exemple
Open connection 10.0.0.42 port = $ { PORT } alias = exemple
Options de fichiers de liste = -lh
 Liste des fichiers path = / tmp options = -l

*** Mots clés ***

Fichiers de liste
[ Arguments ] $ { path } =. $ { options } =
Commande d'exécution ls $ { options } $ { path }

Arguments de mots clés gratuits

Robot Framework 2.8 a ajouté la prise en charge des arguments de mots clés libres de
style Python ( **kwargs). Cela signifie que les mots-clés peuvent recevoir tous les
arguments qui utilisent la name=valuesyntaxe et ne correspondent à aucun autre
argument comme kwargs.

Les arguments de mots clés gratuits prennent en charge les variables de la même
manière que les arguments nommés . En pratique, cela signifie que les variables
peuvent être utilisées à la fois dans les noms et les valeurs, mais que le signe
d'échappement doit toujours être visible littéralement. Par exemple,
les deux foo=${bar}et ${foo}=${bar}sont valides, tant que les variables qui sont
utilisées existent. Une limitation supplémentaire est que les noms d'argument de
mots clés gratuits doivent toujours être des chaînes. La prise en charge des
variables dans les noms est une nouvelle fonctionnalité de Robot Framework 2.8.6,
avant que les variables possibles ne soient pas résolues.

Initialement, les arguments de mots-clés libres fonctionnaient uniquement avec les

bibliothèques basées sur Python, mais Robot Framework 2.8.2 étendait le support
de l' API de bibliothèque dynamique et Robot Framework 2.8.3 l'étendait davantage
aux bibliothèques basées sur Java et à l' interface de bibliothèque distante . Enfin, les
mots-clés utilisateur ont été pris en charge par kwargsdans Robot Framework 2.9. En
d'autres termes, tous les mots-clés peuvent désormais prendre en charge kwargs.

Kwargs exemples

En tant que premier exemple d'utilisation de kwargs, jetons un coup d'œil au mot
clé Run Process dans la bibliothèque Process . Il a une signature command,
*arguments, **configuration, ce qui signifie qu'il faut la commande pour exécuter
( command), ses arguments en tant que nombre variable d'arguments ( *arguments) et
enfin les paramètres de configuration facultatifs en tant qu'arguments de mots clés
libres ( **configuration). L'exemple ci-dessous montre également que les variables
fonctionnent avec des arguments de mots clés libres exactement comme lorsque
vous utilisez la syntaxe de l'argument nommé .
*** Cas de test ***
Utiliser Kwargs
Exécuter le programme program.py arg1 arg2 cwd = / home / user
Exécuter le processus program.py argument shell = True env = $ {
ENVIRON }
Voir la section Arguments relatifs aux mots clés gratuits (** kwargs) sous Création de
bibliothèques de tests pour plus d'informations sur l'utilisation de la syntaxe kwargs
dans vos bibliothèques de tests personnalisées.

Comme deuxième exemple, créons un mot-clé utilisateur pour

l'exécution program.pyde l'exemple ci-dessus. Le mot-clé wrapper Run
Program accepte un nombre quelconque d'arguments et de kwargs, et les transmet
pour Run Process avec le nom de la commande à exécuter.
*** Cas de test ***
Utiliser Kwargs
Exécuter le programme arg1 arg2 cwd = / home / user
Exécuter le programme l' argument shell = True env = $ { ENVIRON }

*** Mots clés ***

Exécuter de programme
[ Arguments ] @ { arguments } & { configuration }
Exécuter le processus program.py @ { arguments } & { configuration }

Arguments incorporés aux noms de mots clés

Une approche totalement différente pour spécifier des arguments consiste à les
incorporer dans des noms de mots-clés. Cette syntaxe est prise en charge par
les mots - clés de la bibliothèque de testset les mots-clés des utilisateurs .

2.2.3 Défaillances
Lorsque le test échoue
Un cas de test échoue si l'un des mots clés qu'il utilise échoue. Normalement, cela
signifie que l'exécution de ce test est arrêtée, qu'un éventuel démontage de test est
exécuté et que l'exécution continue à partir du prochain test. Il est également
possible d'utiliser des échecs continus spéciaux si l'arrêt de l'exécution du test n'est
pas souhaité.

Messages d'erreur
Le message d'erreur affecté à un test élémentaire ayant échoué est obtenu
directement à partir du mot clé en échec. Le message d'erreur est souvent créé par
le mot-clé lui-même, mais certains mots-clés permettent de les configurer.

Dans certaines circonstances, par exemple lorsque des défaillances permanentes

sont utilisées, un scénario de test peut échouer plusieurs fois. Dans ce cas, le
message d'erreur final est obtenu en combinant les erreurs individuelles. De très
longs messages d'erreur sont automatiquement coupés du centre pour que
les rapports soient plus faciles à lire. Les messages d'erreur complets sont toujours
visibles dans le fichier journal en tant que message du mot clé en échec.
Par défaut, les messages d'erreur sont du texte normal, mais à partir de Robot
Framework 2.8, ils peuvent contenir une mise en forme HTML . Ceci est activé en
lançant le message d'erreur avec la chaîne de marqueur *HTML*. Ce marqueur sera
supprimé du message d'erreur final affiché dans les rapports et les
journaux. L'utilisation de HTML dans un message personnalisé est illustrée dans le
deuxième exemple ci-dessous.
*** Cas de test ***
Erreur normale
Fail C'est un exemple plutôt ennuyeux ...

Erreur HTML
$ { number } = obtenir le numéro
Devrait être égal à $ { number } 42 * HTML * Le numéro n'est
pas mon numéro <b> MAGIC </ b>.

2.2.4 Nom du cas de test et documentation

Le nom du scénario de test provient directement de la table Test Case: c'est
exactement ce qui est entré dans la colonne du scénario de test. Les cas de test dans
une suite de tests doivent avoir des noms uniques. Vous pouvez également utiliser
la variable automatique ${TEST_NAME} dans le test lui-même pour faire référence au
nom du test. Il est disponible chaque fois qu'un test est en cours d'exécution, y
compris tous les mots-clés des utilisateurs, ainsi que la configuration du test et le
démontage des tests.

Le paramètre [Documentation] vous permet de définir une documentation gratuite

pour un scénario de test. Ce texte est affiché dans la sortie de la ligne de
commande, ainsi que les journaux de test et les rapports de test qui en résultent. Il
est possible d'utiliser un formatage HTML simple dans la documentation et
les variables peuvent être utilisées pour rendre la documentation dynamique.

Si la documentation est divisée en plusieurs colonnes, les cellules d'une ligne sont
concaténées avec les espaces. Ceci est principalement utile lorsque vous utilisez
le format HTML et que les colonnes sont étroites. Si la documentation est divisée en
plusieurs lignes , les lignes de documentation créées elles-mêmes sont concaténées à
l'aide de nouvelles lignes . Les nouvelles lignes ne sont pas ajoutées si une ligne se
termine déjà par une nouvelle ligne ou une barre oblique inverse .
*** Cas de test ***
Simple
[ Documentation ] Documentation simple
Pas d'opération

Mise en forme
[ Documentation ] * Ceci est en gras *, c'est italique_ et voici un
lien: http://robotframework.org
Pas d'opération

Les variables
 [ Documentation ] Exécutée à $ { HOST } par $ { USER }
Aucune opération

Scission
[ Documentation ] Cette documentation est divisée en plusieurs
colonnes
Pas d'opération

Beaucoup de lignes
[ Documentation ] Nous avons ici
... une nouvelle ligne automatique
Pas d'opération

Il est important que les scénarios de test aient des noms clairs et descriptifs et, dans
ce cas, ils n’ont normalement pas besoin de documentation. Si la logique du
scénario de test nécessite une documentation, cela signifie souvent que les mots-
clés du scénario de test nécessitent de meilleurs noms et qu’ils doivent être
améliorés, au lieu d’ajouter de la documentation supplémentaire. Enfin, les
métadonnées, telles que l'environnement et les informations utilisateur dans le
dernier exemple ci-dessus, sont souvent mieux spécifiées à l'aide de balises .

2.2.5 Marquage des cas de test

L'utilisation de balises dans Robot Framework est un mécanisme simple mais
puissant pour classer les scénarios de test. Les balises sont du texte libre et peuvent
être utilisées au moins aux fins suivantes:

 Les balises sont affichées dans les rapports de test , les journaux et, bien
entendu, dans les données de test. Elles fournissent donc des métadonnées
aux cas de test.
 Les statistiques sur les scénarios de test (total, réussi, échoué sont
automatiquement collectées en fonction des balises).
 Avec les tags, vous pouvez inclure ou exclure des cas de test à exécuter.
 Avec les tags, vous pouvez spécifier quels cas de test sont considérés
comme critiques .

Dans cette section, il est uniquement expliqué comment définir des balises pour les
scénarios de test, et différentes manières de le faire sont répertoriées ci-
dessous. Ces approches peuvent naturellement être utilisées ensemble.

Forcer les balises dans le tableau des paramètres

Tous les scénarios de test dans un fichier de scénario de test avec ce
paramètre obtiennent toujours les balises spécifiées. Si elle est utilisée
dans test suite initialization file, tous les cas de test dans les sous-
suites de test reçoivent ces balises.
Balises par défaut dans le tableau des paramètres
 Les cas de test qui n'ont pas de paramètre [Tags] ont eux-mêmes ces
tags. Les balises par défaut ne sont pas prises en charge dans les fichiers
d'initialisation de la suite de tests.
[Tags] dans le tableau Test Case
Un cas de test obtient toujours ces balises. De plus, les balises possibles ne
sont pas spécifiées avec les balises par défaut . Il est donc possible de
remplacer les balises par défaut en utilisant une valeur vide. Il est également
possible d'utiliser value NONEpour remplacer les tags par défaut.
Option de ligne de commande --settag
Tous les cas de test exécutés reçoivent des tags avec cette option en plus des
tags qu'ils ont obtenus ailleurs.
Définir des mots - clés , supprimer des mots - clés , échec et réussite des mots-clés
d' exécution
Ces mots-clés BuiltIn peuvent être utilisés pour manipuler les balises de
manière dynamique pendant l'exécution du test.

Les balises sont du texte libre, mais elles sont normalisées pour être converties en
minuscules et tous les espaces sont supprimés. Si un scénario de test reçoit la même
balise plusieurs fois, d'autres occurrences que la première sont supprimées. Les
balises peuvent être créées à l'aide de variables, en supposant que ces variables
existent.
*** Paramètres ***
Balises de force req-42
Default Tags propriétaire-john smoke

*** Variables ***

$ { HOST } 10.0.1.42

*** Cas de test ***

Pas de balises propres
[ Documentation ] Ce test a des balises owner-john, smoke et req-
42.
Pas d'opération

Avec ses propres balises

[ Documentation ] Ce test a des balises not_ready, owner-mrx et
req-42.
[ Tags ] propriétaire-mrx not_ready
Pas d'opération

Propres étiquettes avec variables

[ Documentation ] Ce test a des balises host-10.0.1.42 et req-42.
[ Tags ] host- $ { HOST }
Aucune opération

Vider les balises propres

[ Documentation ] Ce test n'a que le tag req-42.
[ Tags ]
Aucune opération

Définir les mots-clés et supprimer les mots-clés

 [ Documentation ] Ce test a des balises mytag et owner-john.
Set Tags mytag
Supprimer les étiquettes fume req- *

Tags réservés
Les utilisateurs sont généralement libres d'utiliser les balises qui fonctionnent dans
leur contexte. Il existe toutefois certaines balises qui ont une signification
prédéfinie pour Robot Framework lui-même, et leur utilisation à d'autres fins peut
avoir des résultats inattendus. Toutes les balises spéciales que Robot Framework a
et auront à l’avenir robot-ou bien un robot:préfixe. Pour éviter les problèmes, les
utilisateurs ne doivent donc utiliser aucune balise avec ces préfixes, à moins
d'activer la fonctionnalité spéciale.

Au moment de l'écriture, les seules balises spéciales sont celles robot-exitqui sont
automatiquement ajoutées aux tests lors de l' arrêt normal de l'exécution des tests ,
et robot:no-dry-runqui peuvent être utilisées pour désactiver le mode
de fonctionnement à sec . D'autres utilisations seront probablement ajoutées dans le
futur.

Remarque

Le plan consiste à unifier les préfixes réservés à l'avenir. Très probablement, le robot:préfixe
sera utilisé avec toutes les balises réservées, mais il est préférable d'éviter ces deux préfixes
pour le moment. Voir le numéro 2539 pour plus de détails.

2.2.6 Configuration du test et démontage

Robot Framework possède une fonctionnalité de configuration et de suppression
des tests similaire à celle de nombreuses autres structures d'automatisation de
test. En bref, une configuration de test est quelque chose qui est exécuté avant un
test élémentaire, et un démontage de test est exécuté après un test
élémentaire. Dans Robot Framework, les configurations et les démontages ne sont
que des mots-clés normaux avec des arguments possibles.

L'installation et le démontage sont toujours un seul mot clé. S'ils doivent prendre en
charge plusieurs tâches distinctes, il est possible de créer des mots - clés utilisateur
de niveau supérieur à cette fin. Une autre solution consiste à exécuter plusieurs
mots-clés à l'aide du mot-clé BuiltIn Run Mots-clés .

Le démontage de test est spécial de deux manières. Tout d'abord, il est également
exécuté lorsqu'un cas de test échoue. Il peut donc être utilisé pour des activités de
nettoyage à effectuer, quel que soit le statut du test élémentaire. De plus, tous les
mots-clés du démontage sont également exécutés même si l'un d'eux échoue. Cette
fonctionnalité continue sur défaillance peut également être utilisée avec des mots-clés
normaux, mais les démoulages internes sont activés par défaut.
Le moyen le plus simple de spécifier une configuration ou une suppression pour les
scénarios de test dans un fichier de scénario de test consiste à utiliser
les paramètres Test Setup et Test Teardowndu tableau Setting. Les cas de test
individuels peuvent également avoir leur propre configuration ou suppression. Ils
sont définis avec les paramètres [Setup] ou [Teardown] dans la table des cas de
test et ils remplacent les paramètres possibles de la configuration du test et du test
Teardown . Ne pas avoir de mot-clé après
un réglage [Setup] ou [Teardown] signifie ne pas avoir de configuration ou de
démontage. Il est également possible d'utiliser une valeur NONEpour indiquer qu'un
test n'a pas de configuration / suppression.
*** Paramètres ***
Configuration du test Ouvrir l'application App A
Test Teardown Close Application

*** Cas de test ***

Les valeurs par défaut
[ Documentation ] Configuration et démontage du tableau de réglage
Faire quelque chose

Configuration surchargée
[ Documentation ] Configuration propre, démontage du tableau de
réglage
[ Configuration ] Ouvrez l'application App B
Faire quelque chose

Pas de démontage
[ Documentation ] Configuration par défaut, pas de démontage du
tout
Faire quelque chose
[ Teardown ]

Pas de démontage 2
[ Documentation ] La configuration et le démontage peuvent
également être désactivés avec une valeur spéciale NONE
Faire quelque chose
[ Teardown ] AUCUN

Utiliser des variables

[ Documentation ] Configuration et démontage spécifiés à l'aide de
variables
[ Setup ] $ { SETUP }
Faites quelque chose
[ Teardown ] $ { TEARDOWN }

Le nom du mot-clé à exécuter en tant que configuration ou à supprimer peut être

une variable. Cela facilite les différentes configurations ou démontages dans
différents environnements en attribuant le nom du mot-clé en tant que variable à
partir de la ligne de commande.

Remarque
Les suites de tests peuvent être configurées et démontées . Une installation de suite est
exécutée avant tout test élémentaire ou suite de sous-test dans cette suite de tests. De même,
une suppression de suite est exécutée après celle-ci.

2.2.7 Modèles de test

Les modèles de test convertissent les scénarios de test normaux basés sur des mots-clés
en tests basés sur des données . Alors que le corps d'un test élémentaire piloté par
mots clés est construit à partir de mots clés et de leurs arguments possibles, les
scénarios de test avec template ne contiennent que les arguments du mot clé
template. Au lieu de répéter le même mot-clé plusieurs fois par test et / ou avec
tous les tests d'un fichier, il est possible de l'utiliser uniquement par test ou une
seule fois par fichier.

Les mots clés de modèle peuvent accepter à la fois des arguments positionnels et
nommés normaux, ainsi que des arguments incorporés au nom du mot
clé. Contrairement à d'autres paramètres, il n'est pas possible de définir un modèle à
l'aide d'une variable.

Utilisation de base
La façon dont un mot clé acceptant des arguments de position normaux peut être
utilisé comme modèle est illustrée par les exemples de cas de test suivants. Ces
deux tests sont fonctionnellement totalement identiques.
*** Cas de test **
Cas de test normal
Exemple de mot clé premier argument second argument

Cas de test basé sur des modèles

[ Template ] Exemple de mot-clé
premier argument deuxième argument

Comme l'illustre l'exemple, il est possible de spécifier le modèle pour un scénario

de test individuel à l'aide du paramètre [Template] . Une autre approche consiste à
utiliser le paramètre Modèle de test du tableau Paramètres, auquel cas le modèle est
appliqué à tous les scénarios de test dans ce fichier de scénario de
test. Le paramètre [Template] remplace le modèle possible défini dans le tableau
Setting et une valeur vide pour [Template] signifie que le test n'a pas de modèle,
même lorsque le modèle de test est utilisé. Il est également possible d'utiliser une
valeur NONEpour indiquer qu'un test n'a pas de modèle.

Si un scénario de test basé sur un modèle contient plusieurs lignes de données dans
son corps, le modèle est appliqué à toutes les lignes une par une. Cela signifie que
le même mot-clé est exécuté plusieurs fois, une fois avec des données sur chaque
ligne. Les tests basés sur des modèles sont également spéciaux, de sorte que tous
les tours sont exécutés même si un ou plusieurs d'entre eux échouent. Il est possible
d'utiliser ce type de mode continu sur échec avec des tests normaux également, mais
avec les tests basés sur des modèles, le mode est activé automatiquement.
*** Paramètres ***
Exemple de mot-clé de modèle de test

*** Cas de test ***

Cas de test basé sur des modèles
premier tour 1 premier tour 2
deuxième tour 1 deuxième tour 2
troisième tour 1 troisième tour 2

L'utilisation d'arguments avec des valeurs par défaut ou varargs , ainsi que l'utilisation
d' arguments nommés et d'arguments de mots clés gratuits , fonctionnent avec les
modèles exactement comme ils fonctionnent. L'utilisation de variables dans les
arguments est également prise en charge normalement.

Modèles avec arguments incorporés

À partir de Robot Framework 2.8.2, les modèles prennent en charge une variante de
la syntaxe des arguments incorporés . Avec les modèles, cette syntaxe fonctionne de
sorte que si le mot-clé du modèle contient des variables, celles-ci sont considérées
comme des espaces réservés aux arguments et remplacées par les arguments réels
utilisés avec le modèle. Le mot-clé résultant est ensuite utilisé sans arguments de
position. Ceci est mieux illustré avec un exemple:
*** Cas de test ***
Cas de test normal avec des arguments incorporés
Le résultat de 1 + 1 devrait être 2
Le résultat de 1 + 2 devrait être 3

Modèle avec arguments incorporés

[ Template ] Le résultat de $ { calculation } devrait être $ {
attendu }
1 + 1 2
1 + 2 3

*** Mots clés ***

Le résultat de $ { ignement } devrait être $ { prévu }
$ { résultat } = Calculer $ { calcul }
Doit être égal à $ { résultat } $ { prévu }

Lorsque des arguments incorporés sont utilisés avec des modèles, le nombre
d'arguments dans le nom du mot clé du modèle doit correspondre au nombre
d'arguments utilisés. Les noms d'argument n'ont pas besoin de correspondre aux
arguments du mot clé d'origine, cependant, et il est également possible d'utiliser des
arguments différents:
*** Cas de test ***
Noms d'argument différents
[ Template ] Le résultat de $ { foo } devrait être $ { bar }
1 + 1 2
1 + 2 3
Seuls quelques arguments
[ Template ] Le résultat de $ { measurement } devrait être 3
1 + 2
4 - 1

Nouveaux arguments
[ Template ] Le $ { signifie } de $ { life } devrait être 42
résultat 21 * 2

Le principal avantage de l'utilisation d'arguments incorporés avec des modèles est

que les noms d'argument sont spécifiés explicitement. Lorsque vous utilisez des
arguments normaux, vous pouvez obtenir le même effet en nommant les colonnes
contenant des arguments. Ceci est illustré par l' exemple de style axé
sur les données dans la section suivante.

Modèles avec pour boucles

Si des modèles sont utilisés avec des boucles for , le modèle est appliqué à toutes les
étapes de la boucle. Le mode continuer en cas d'échec est également utilisé dans ce
cas, ce qui signifie que toutes les étapes sont exécutées avec tous les éléments en
boucle, même s'il y a des défaillances.
*** Cas de test ***
Template et pour
[ Template ] Exemple de mot-clé
: FOR $ { item } IN @ { ITEMS }
\ $ { item } 2ème argument
: POUR $ { index } DANS LA GAMME 42
\ 1er argument $ { index }

2.2.8 Différents styles de cas de test

Il existe plusieurs manières différentes d’écrire des cas de test. Les scénarios de test
décrivant un type de flux de travail peuvent être écrits dans un style axé sur les
mots-clés ou les comportements. Le style axé sur les données peut être utilisé pour
tester le même flux de travail avec des données d'entrée variables.

Style axé sur les mots clés

Les tests de flux de travail, tels que le test de connexion valide décrit précédemment ,
sont construits à partir de plusieurs mots-clés et de leurs arguments possibles. Leur
structure normale est que d' abord le système est pris en l'état initial ( Ouvrir page
de connexion dans la connexion valide par exemple), alors quelque chose est fait
pour le système ( Nom d'entrée , mot de passe d' entrée , de soumettre
des pouvoirs ), et enfin , il est vérifié que le le système s'est comporté comme prévu
(la page d'accueil devrait être ouverte ).

Style axé sur les données

Un autre style d'écriture de cas de test est l' approche basée sur les données , où les
scénarios de test utilisent uniquement un mot clé de niveau supérieur, normalement
créé en tant que mot clé utilisateur , qui masque le flux de travaux de test réel. Ces
tests sont très utiles lorsqu'il est nécessaire de tester le même scénario avec des
données d'entrée et / ou de sortie différentes. Il serait possible de répéter le même
mot-clé à chaque test, mais la fonctionnalité du modèle de test permet de spécifier le
mot-clé à utiliser une seule fois.
*** Paramètres ***
La connexion de modèle de test avec des informations d'identification non
valides doit échouer

*** Cas de test *** MOT DE PASSE USERNAME

Nom d'utilisateur invalide invalide $ { VALID PASSWORD } Mot
de passe invalide $ { VALID USER } invalide

Nom d'utilisateur et mot de passe non valides non valides

Nom d'utilisateur vide $ { VIDE } $ { MOT DE PASSE VALID
}
Mot de passe vide $ { UTILISATEUR VALIDE } $ { EMPTY }
Nom d'utilisateur et mot de passe vides $ { EMPTY } $ { EMPTY }

Pointe

Nommer des colonnes comme dans l'exemple ci-dessus facilite la compréhension des
tests. Ceci est possible car sur la ligne d'en-tête, les autres cellules sauf la première sont
ignorées .

L’exemple ci-dessus comporte six tests distincts, un pour chaque combinaison

utilisateur / mot de passe non valide, et l’exemple ci-dessous montre comment
n’avoir qu’un seul test avec toutes les combinaisons. Lors de l'utilisation de modèles
de test , tous les tours d'un test sont exécutés même s'il y a des défaillances. Il n'y a
donc pas de différence fonctionnelle réelle entre ces deux styles. Dans l'exemple ci-
dessus, des combinaisons distinctes sont nommées afin qu'il soit plus facile de voir
ce qu'elles testent, mais le nombre potentiellement élevé de ces tests peut perturber
les statistiques. Le style à utiliser dépend du contexte et des préférences
personnelles.
*** Cas de test ***
Mot de passe incorrect
[ Template ] La connexion avec des informations d'identification
non valides doit échouer
invalide $ { VALID PASSWORD }
$ { VALID USER } invalide
invalide quoi que ce soit
$ { VIDE } $ { MOT DE PASSE VALIDE }
$ { UTILISATEUR VALIDE } $ { EMPTY }
$ { EMPTY } $ { EMPTY }

Style axé sur le comportement

Il est également possible d'écrire des cas de test en tant qu'exigences que les parties
prenantes non techniques du projet doivent également comprendre. Ces exigences
en matière d’exécutables sont la pierre angulaire d’un processus communément
appelé ATDD ( Acceptance Test Driven Development ) ou Specification by Example .

Une façon d'écrire ces exigences / tests est le style Given-When-Then popularisé
par BDHD ( Behavior Driven Development ). Lors de l' écriture des cas de test dans ce
style, l'état initial est généralement exprimée avec un mot - clé commençant par
mot donné , les actions sont décrites avec mot - clé à partir de quand et les attentes
avec un mot - clé à partir de puis . Le mot-clé commençant par And ou But peut être
utilisé si une étape comporte plusieurs actions.
*** Cas de test ***
Login valide
La page de connexion donnée est ouverte
Lorsque le nom d'utilisateur et le mot de passe sont insérés
et les informations d'identification sont soumises
Alors la page d'accueil devrait être ouverte

Ignorer les préfixes Given / When / Then / And / But

Les préfixes donnés , When , Then , And et But sont supprimés lorsque des mots-
clés correspondants sont recherchés, si aucune correspondance avec le nom
complet n'est trouvée. Cela fonctionne pour les mots-clés d'utilisateur et de
bibliothèque. Par exemple, la page de connexion donnée est ouverte dans l'exemple
ci-dessus et peut être implémentée en tant que mot-clé utilisateur avec ou sans le
mot donné . Ignorer les préfixes permet également d'utiliser le même mot clé avec
des préfixes différents. Par exemple, la page d'accueil devrait être ouverte pourrait
également être utilisée comme Et la page d'accueil devrait être ouverte .

Remarque

Ignorer Mais le préfixe est nouveau dans Robot Framework 2.8.7.

Incorporation de données à des mots-clés

Lors de l'écriture d'exemples concrets, il est utile de pouvoir transmettre les

données réelles aux implémentations de mots clés. Les mots-clés utilisateur le
permettent en intégrant des arguments au nom du mot-clé .

2.3 Création de suites de tests

Les scénarios de test de la structure de robot sont créés dans des fichiers de
scénarios de test, qui peuvent être organisés en répertoires. Ces fichiers et
répertoires créent une structure de suite de tests hiérarchique.

 2.3.1 Fichiers de cas de test

  2.3.2 Répertoires de la suite de tests
o Avertissement sur les fichiers non valides
o Fichiers d'initialisation
 2.3.3 Nom de la suite de tests et documentation
 2.3.4 Métadonnées de la suite de tests gratuite
 2.3.5 Configuration et démontage de la suite

2.3.1 Fichiers de cas de test

Les scénarios de test de la structure de robot sont créés à l' aide de tables de scénarios
de test dans des fichiers de scénarios de test. Un tel fichier crée automatiquement
une suite de tests à partir de tous les cas de test qu'il contient. Il n'y a pas de limite
supérieure pour le nombre de cas de test possibles, mais il est recommandé d'en
avoir moins de dix, à moins d' utiliser l' approche pilotée par les données , où un seul
test comporte un seul mot clé de haut niveau.

Les paramètres suivants du tableau Paramètres peuvent être utilisés pour

personnaliser la suite de tests:

Documentation
Utilisé pour spécifier une documentation de suite de tests
Métadonnées
Utilisé pour définir des métadonnées de suite de tests gratuites en tant que paires
nom-valeur.
Configuration Suite , Teardown Suite
Spécifiez la configuration et le démontage de la suite .

Remarque

Tous les noms des paramètres peuvent éventuellement inclure deux points à la fin, par
exemple Documentation: . Cela peut faciliter la lecture des paramètres, en particulier lorsque
vous utilisez le format texte brut.

2.3.2 Répertoires de la suite de tests

Les fichiers de cas de test peuvent être organisés en répertoires et ces répertoires
créent des suites de tests de niveau supérieur. Une suite de tests créée à partir d'un
répertoire ne peut pas contenir directement de scénarios de test, mais contient plutôt
d'autres suites de tests avec des scénarios de test. Ces répertoires peuvent ensuite
être placés dans d'autres répertoires, créant ainsi une suite de niveau supérieur. Il
n'y a pas de limites pour la structure, donc les cas de test peuvent être organisés
selon les besoins.

Lorsqu'un répertoire de test est exécuté, les fichiers et répertoires qu'il contient sont
traités récursivement comme suit:
  Les fichiers et répertoires dont le nom commence par un point ( . ) Ou un
trait de soulignement ( _ ) sont ignorés.
 Les répertoires avec le nom CVS sont ignorés (sensibles à la casse).
 Fichiers n'ayant pas l'une des extensions
reconnues ( .html , .xhtml , .htm , .tsv , .txt , .rst , .rest ou .robot ) sont ignorés
(insensible à la casse).
 D'autres fichiers et répertoires sont traités.

Si un fichier ou un répertoire traité ne contient aucun cas de test, il est

silencieusement ignoré (un message est écrit dans le journal système ) et le traitement
se poursuit.

Avertissement sur les fichiers non valides

Normalement, les fichiers qui ne possèdent pas une table de cas de test valide sont
ignorés en silence avec un message écrit dans le journal système . Il est possible
d'utiliser une option de ligne de commande --warnonskippedfiles , qui
transforme le message en un avertissement affiché dans les erreurs d'exécution de test .

Fichiers d'initialisation
Une suite de tests créée à partir d'un répertoire peut avoir des paramètres similaires
à ceux d'une suite créée à partir d'un fichier de scénario de test. Un répertoire seul
ne pouvant pas contenir ce type d'informations, il doit être placé dans un fichier
d'initialisation de la suite de tests spéciale. Un nom de fichier d'initialisation doit
toujours être au format __init __. Ext , où l'extension doit être l'un des formats de
fichiers pris en charge (par exemple, __init __. Robot ou __init __. Html ). Le format
de nom est emprunté à Python, où les fichiers nommés de cette manière indiquent
qu'un répertoire est un module.

Les fichiers d'initialisation ont la même structure et la même syntaxe que les
fichiers de cas de test, sauf qu'ils ne peuvent pas contenir de tables de scénarios de
test et que tous les paramètres ne sont pas pris en charge. Variables et mots-clés
créés ou importés dans les fichiers d'initialisation sont pas disponibles dans les
suites de tests de niveau inférieur. Si vous devez partager des variables ou des
mots-clés, vous pouvez les placer dans des fichiers de ressources pouvant être
importés à la fois par des fichiers d'initialisation et de test.

L'utilisation principale des fichiers d'initialisation consiste à spécifier les

paramètres liés à la suite de tests de la même manière que dans les fichiers de cas de
test , mais en définissant paramètres liés aux scénarios de test est également
possible. Comment utiliser différents paramètres dans les fichiers d'initialisation est
expliqué ci-dessous.
Documentation , les métadonnées , le programme d' installation de
Suite , Teardown Suite
Ces paramètres spécifiques aux suites de tests fonctionnent de la même
manière que dans les fichiers de scénarios de test.
Balises de force
Les balises spécifiées sont définies inconditionnellement sur tous les cas de
test dans tous les fichiers de cas de test que ce répertoire contient
directement ou récursivement.
Configuration du test , test de déchirement , expiration du test
Définissez la valeur par défaut pour la configuration / le démontage du test
ou le délai d'expiration du test pour tous les scénarios de test contenus dans
ce répertoire. Peut être remplacé au niveau inférieur. La prise en charge de la
définition du délai d'expiration du test dans les fichiers d'initialisation a été
ajoutée dans Robot Framework 2.7.
Balises par défaut , modèle de test
Non pris en charge dans les fichiers d'initialisation.
*** Paramètres ***
Documentation Suite de
Configuration de la suite Faire quelque chose $ { MESSAGE } Forcer les
balises
Exemple de
Bibliothèque SomeLibrary

*** Variables ***

$ { MESSAGE } Bonjour tout le monde!

*** Mots clés ***

Faire quelque chose
[ Arguments ] $ { args }
Quelques mots-clés $ { arg } Un autre mot-clé

2.3.3 Nom de la suite de tests et documentation

Le nom de la suite de tests est construit à partir du nom du fichier ou du
répertoire. Le nom est créé pour que l'extension soit ignorée, les traits de
soulignement possibles sont remplacés par des espaces et les noms entièrement en
minuscule sont remplis par un titre. Par exemple, some_tests.html devient Some
Tests et My_test_directory devient My test directory .

Le nom du fichier ou du répertoire peut contenir un préfixe pour contrôler l' ordre
d'exécution des suites. Le préfixe est séparé du nom de base par deux traits de
soulignement et, lors de la construction du nom de la suite de tests, le préfixe et les
traits de soulignement sont supprimés. Par exemple, les
fichiers 01__some_tests.txt et 02__more_tests.txt créent des suites de tests.
Quelques tests et plusieurs tests , respectivement, et le premier est exécuté avant ce
dernier.
La documentation d'une suite de tests est définie à l'aide
du paramètre Documentation dans le tableau Paramètres. Il peut être utilisé dans les
fichiers de cas de test ou, avec les suites de niveau supérieur, dans les fichiers
d'initialisation de la suite de tests. La documentation de la suite de tests a
exactement les mêmes caractéristiques quant à son affichage et à sa création en tant
que documentation de cas de test .
*** Paramètres ***
Documentation Exemple de documentation de la suite de tests avec * some *
_formatting_.
... Voir la documentation de test pour plus d'exemples de
documentation.

Tant le nom que la documentation de la suite de tests de niveau supérieur peuvent

être remplacés lors de l'exécution du test. Cela peut être fait avec les options de
ligne de commande --name et --doc, respectivement, comme expliqué dans la
section Définition des métadonnées .

2.3.4 Métadonnées de la suite de tests gratuite

Les suites de tests peuvent également avoir d'autres métadonnées que la
documentation. Ces métadonnées sont définies dans la table Setting à l'aide
des métadonnées. paramètre . Les métadonnées ainsi définies sont affichées dans
les rapports de test et les journaux.

Le nom et la valeur des métadonnées se trouvent dans les colonnes qui suivent
les métadonnées . La valeur est gérée de la même manière que la documentation, ce
qui signifie qu'elle peut être divisée en plusieurs cellules (jointes par des espaces)
ou en plusieurs lignes (réunies par des nouvelles lignes), de simples mises en forme
HTML et même des variables .

*** Paramètres ***

Version de métadonnées 2.0
Métadonnées Plus d'informations Pour plus d'informations sur * Robot
Framework *, voir http://robotframework.org
Métadonnées exécutées à $ { HOST }

Pour les suites de tests de niveau supérieur, il est également possible de définir des
métadonnées avec l' option de ligne de commande --metadata . Ceci est discuté
plus en détail dans la section Définition des métadonnées .

2.3.5 Configuration et démontage de la suite

Non seulement les cas de test mais aussi les suites de tests peuvent avoir une
configuration et un démontage. Une installation de la suite est exécutée avant
d’exécuter les scénarios de test ou les suites de test enfants de la suite, et un
démontage de test est exécuté après eux. Toutes les suites de tests peuvent être
configurées et démontées. avec les suites créées à partir d'un répertoire, elles
doivent être spécifiées dans un fichier d'initialisation de suite de tests .

De même que pour les scénarios de test, une installation et un démontage de la

suite sont des mots-clés qui peuvent prendre des arguments. Ils sont définis dans le
tableau des paramètres avec laconfiguration de la suite et la suppression de la
suite. , respectivement. Les noms de mots-clés et les arguments possibles se
trouvent dans les colonnes après le nom du paramètre.

Si la configuration d'une suite échoue, tous les scénarios de test et ses suites de tests
enfants reçoivent immédiatement un statut d'échec et ne sont pas exécutés. Cela
rend les configurations de la suite idéales pour vérifier les conditions préalables qui
doivent être remplies avant de pouvoir exécuter des cas de test.

Un démontage de la suite est normalement utilisé pour le nettoyage une fois que
tous les cas de test ont été exécutés. Il est exécuté même si la configuration de la
même suite échoue. Si le démontage de la suite échoue, tous les scénarios de test de
la suite ont été marqués comme ayant échoué, quel que soit leur statut d'exécution
d'origine. Notez que tous les mots-clés dans les démontages de la suite sont
exécutés même si l'un d'eux échoue.

Le nom du mot-clé à exécuter en tant que configuration ou à supprimer peut être

une variable. Cela facilite les différentes configurations ou démontages dans
différents environnements en attribuant le nom du mot-clé en tant que variable à
partir de la ligne de commande.

2.4 Utilisation des bibliothèques de tests

Les bibliothèques de test contiennent les mots-clés de niveau le plus bas, souvent
appelés mots - clés de bibliothèque , qui interagissent réellement avec le système
testé. Tous les scénarios de test utilisent toujours des mots-clés provenant d'une
bibliothèque, souvent via des mots - clés d'utilisateur de niveau supérieur . Cette
section explique comment utiliser les bibliothèques de tests et utiliser les mots-clés
fournis. La création de bibliothèques de tests est décrite dans une section distincte.

 2.4.1 Importer des bibliothèques

o En utilisant le Libraryréglage
o En utilisant le Import Librarymot clé
 2.4.2 Spécification de la bibliothèque à importer
o Utiliser le nom de la bibliothèque
o Utiliser un chemin physique vers la bibliothèque
 2.4.3 Définition d'un nom personnalisé pour tester la bibliothèque
 2.4.4 Bibliothèques standard
o Bibliothèques standard normales
o Bibliothèque à distance
 2.4.5 Bibliothèques externes
2.4.1 Importer des bibliothèques
Les bibliothèques de test sont généralement importées à l'aide
du paramètre Library , mais il est également possible d'utiliser le mot clé Import
Library .

En utilisant le Libraryréglage
Les bibliothèques de test sont normalement importées à l'aide
du paramètre Library dans la table Setting et portant le nom de la bibliothèque dans
la colonne suivante. Contrairement à la plupart des autres données, le nom de la
bibliothèque est sensible à la fois à la casse et à l’espace. Si une bibliothèque est
dans un package, le nom complet, y compris le nom du package, doit être utilisé.

Dans les cas où la bibliothèque a besoin d'arguments, ils sont répertoriés dans les
colonnes après le nom de la bibliothèque. Il est possible d'utiliser les valeurs par
défaut, le nombre variable d'arguments et les arguments nommés dans les
importations de bibliothèques de tests de la même manière qu'avec les arguments des
mots clés . Le nom de la bibliothèque et les arguments peuvent être définis à l'aide
de variables.
*** Paramètres ***
Système d' exploitation de bibliothèque
Bibliothèque my.package.TestLibrary
Bibliothèque MyLibrary arg1 arg2
Bibliothèque $ { LIBRARY }

Il est possible d'importer des bibliothèques de tests dans des fichiers de scénarios
de test , des fichiers de ressources et des fichiers d'initialisation de suites de tests . Dans
tous ces cas, tous les mots-clés de la bibliothèque importée sont disponibles dans ce
fichier. Avec les fichiers de ressources, ces mots-clés sont également disponibles
dans d'autres fichiers les utilisant.

En utilisant le Import Library mot clé

Une autre possibilité d'utiliser une bibliothèque de test consiste à utiliser le mot-
clé Import Library de la bibliothèque BuiltIn . Ce mot clé prend le nom de la
bibliothèque et les arguments possibles de la même manière que
le paramètre Library . Les mots-clés de la bibliothèque importée sont disponibles
dans la suite de tests où le mot-clé Import Library a été utilisé. Cette approche est
utile dans les cas où la bibliothèque n'est pas disponible au démarrage de
l'exécution du test et que seuls certains mots-clés la rendent disponible.
*** Cas de test ***
Exemple
Faire quelque chose
Importer une bibliothèque MyLibrary arg1 arg2
 KW à partir de MyLibrary

2.4.2 Spécification de la bibliothèque à importer

Les bibliothèques à importer peuvent être spécifiées en utilisant le nom de la
bibliothèque ou le chemin d'accès à la bibliothèque. Ces approches fonctionnent de
la même manière, quelle que soit l'import de la bibliothèque à l'aide
du paramètre Library ou du mot clé Import Library .

Utiliser le nom de la bibliothèque

La manière la plus courante de spécifier une bibliothèque de tests à importer est
d'utiliser son nom, comme cela a été fait dans tous les exemples de cette
section. Dans ces cas, Robot Framework tente de trouver la classe ou le module
implémentant la bibliothèque à partir du chemin de recherche du module . Les
bibliothèques installées d'une manière ou d'une autre doivent se trouver
automatiquement dans le chemin de recherche du module, mais avec les autres
bibliothèques, le chemin de recherche peut devoir être configuré séparément.

Le plus grand avantage de cette approche est que lorsque le chemin de recherche du
module a été configuré, souvent à l'aide d'un script de démarrage personnalisé , les
utilisateurs normaux n'ont pas besoin de penser où les bibliothèques sont réellement
installées. L'inconvénient est que la création de vos propres bibliothèques, très
simples dans le chemin de recherche, peut nécessiter une configuration
supplémentaire.

Utiliser un chemin physique vers la bibliothèque

Un autre mécanisme permettant de spécifier la bibliothèque à importer consiste à
utiliser un chemin dans le système de fichiers. Ce chemin est considéré comme
relatif au répertoire où le fichier de données de test actuel se trouve de la même
manière que les chemins d'accès aux fichiers de ressources et aux fichiers de
variables . Le principal avantage de cette approche est qu’il n’est pas nécessaire de
configurer le chemin de recherche du module.

Si la bibliothèque est un fichier, le chemin d'accès doit contenir une extension. Pour
les bibliothèques Python, l'extension est naturellement .py et pour les bibliothèques
Java, elle peut être soit .classou .java , mais le fichier de classe doit toujours être
disponible. Si la bibliothèque Python est implémentée en tant que répertoire, son
chemin doit comporter une barre oblique ( /). Les exemples suivants démontrent
ces différents usages.
*** Paramètres ***
Bibliothèque PythonLibrary.py
Bibliothèque /absolute/path/JavaLibrary.java
Bibliothèque relative / chemin / PythonDirLib / arguments possibles
Bibliothèque $ { RESOURCES } /Example.class

Une limitation de cette approche est que les bibliothèques implémentées en tant que
classes Python doivent se trouver dans un module du même nom que la classe . De plus,
l'importation de bibliothèques distribuées dans des packages JAR ou ZIP n'est pas
possible avec ce mécanisme.

2.4.3 Définition d'un nom personnalisé pour tester la

bibliothèque
Le nom de la bibliothèque est affiché dans les journaux de test avant les noms de
mots-clés. Si plusieurs mots-clés portent le même nom, ils doivent être utilisés pour
que le nom du mot - clé soit précédé du nom de la bibliothèque . Le nom de la
bibliothèque provient normalement du nom du module ou de la classe qui
l'implémente, mais dans certaines situations, il est souhaitable de le modifier:

 Il est nécessaire d'importer la même bibliothèque plusieurs fois avec des

arguments différents. Ce n'est pas possible autrement.
 Le nom de la bibliothèque est trop long. Cela peut se produire, par exemple,
si une bibliothèque Java a un nom de package long.
 Vous voulez utiliser des variables pour importer différentes bibliothèques
dans différents environnements, mais faites-les référence avec le même nom.
 Le nom de la bibliothèque est trompeur ou médiocre. Dans ce cas, changer le
nom actuel est bien sûr une meilleure solution.

La syntaxe de base pour spécifier le nouveau nom est d'avoir le texte WITH
NAME(sensible à la casse) après le nom de la bibliothèque, puis d'avoir le nouveau
nom dans la cellule suivante. Le nom spécifié est affiché dans les journaux et doit
être utilisé dans les données de test lors de l'utilisation du nom complet des mots-
clés ( LibraryName.Keyword Name ).
*** Paramètres ***
Bibliothèque com.company.TestLib AVEC NAME TestLib
Bibliothèque $ { LIBRARY } WITH NAME MyName

Les arguments possibles à la bibliothèque sont placés dans des cellules entre le nom
de la bibliothèque d'origine et le WITH NAMEtexte. L'exemple suivant illustre
comment la même bibliothèque peut être importée plusieurs fois avec des
arguments différents:
*** Paramètres ***
Bibliothèque SomeLibrary localhost 1234 WITH NAME LocalLib
Bibliothèque SomeLibrary server.domain 8080 AVEC NOM RemoteLib

*** Cas de test ***

Mon test
LocalLib.Some Mot-clé some arg second arg
 RemoteLib.Some les mots - clés un autre arg tout
LocalLib.Another Mot-clé

La définition d'un nom personnalisé sur une bibliothèque de test fonctionne à la fois
lors de l'importation d'une bibliothèque dans la table Setting et lors de l'utilisation
du mot clé Import Library .

2.4.4 Bibliothèques standard

Certaines bibliothèques de tests sont distribuées avec Robot Framework et ces
bibliothèques sont appelées bibliothèques standard . La bibliothèque BuiltIn est
spéciale car elle est utilisée automatiquement et ses mots-clés sont toujours
disponibles. Les autres bibliothèques standard doivent être importées de la même
manière que les autres bibliothèques, mais il n’est pas nécessaire de les installer.

Bibliothèques standard normales

Les bibliothèques standard disponibles sont répertoriées ci-dessous avec des liens
vers leurs documentations:

 BuiltIn
 Collections
 DateTime
 Dialogues
 Système opérateur
 Processus
 Capture d'écran
 Chaîne
 Telnet
 XML

Bibliothèque à distance
Outre les bibliothèques standard standard répertoriées ci-dessus, il existe également
une bibliothèque distante totalement différente des autres bibliothèques standard. Il
ne possède pas de mot-clé mais fonctionne comme un proxy entre Robot
Framework et les implémentations réelles des bibliothèques de tests. Ces
bibliothèques peuvent être exécutées sur d'autres machines que le framework
principal et peuvent même être implémentées en utilisant des langages non pris en
charge par Robot Framework de manière native.

Voir la section séparée Interface de la bibliothèque distante pour plus d'informations

sur ce concept.
2.4.5 Bibliothèques externes
Toute bibliothèque de test qui ne fait pas partie des bibliothèques standard est, par
définition, une bibliothèque externe . La communauté open source de Robot
Framework a implémenté plusieurs bibliothèques génériques, telles
que SeleniumLibrary et SwingLibrary , qui ne sont pas intégrées au framework
principal. Une liste des bibliothèques accessibles au public peut être trouvée
sur http://robotframework.org .

Les bibliothèques génériques et personnalisées peuvent évidemment être

implémentées par des équipes utilisant Robot Framework. Voir la section Création
de bibliothèques de tests pour plus d'informations sur ce sujet.

Différentes bibliothèques externes peuvent avoir un mécanisme totalement différent

pour les installer et les utiliser. Parfois, d'autres dépendances doivent être installées
séparément. Toutes les bibliothèques doivent disposer d'une documentation claire
sur l'installation et l'utilisation, et elles doivent de préférence automatiser le
processus d'installation.

2.5 Variables
 2.5.1 Introduction
 2.5.2 Types de variables
o Variables scalaires
o Variables de liste
o Variables du dictionnaire
o Variables d'environnement
o Propriétés du système Java
 2.5.3 Création de variables
o Table variable
o Fichier variable
o Définition des variables en ligne de commande
o Valeurs de retour des mots-clés
o Utilisation des mots-clés Set Test / Suite / Global Variable
 2.5.4 Variables intégrées
o Variables du système d'exploitation
o Les variables numériques
o Variables booléennes et aucune / null
o Espace et variables vides
o Variables automatiques
 2.5.5 Priorités variables et portées
o Priorités variables
o Étendues variables
 2.5.6 Fonctions de variables avancées
o Syntaxe de variable étendue
o Affectation de variables étendue
o Variables à l'intérieur des variables
2.5.1 Introduction
Les variables font partie intégrante de Robot Framework et peuvent être utilisées
dans la plupart des endroits dans les données de test. Le plus souvent, ils sont
utilisés dans les arguments des mots-clés dans les tables de scénarios et les tables
de mots-clés, mais tous les paramètres autorisent également les variables dans leurs
valeurs. Un nom de mot clé normal ne peut pas être spécifié avec une variable,
mais le mot clé BuiltIn Run Keyword peut être utilisé pour obtenir le même effet.

Robot Framework a ses propres variables qui peuvent être utilisées comme
des scalaires , des listes ou des dictionnaires en utilisant
la syntaxe ${SCALAR}, @{LIST}et &{DICT}, respectivement. De plus, les variables
d'environnement peuvent être utilisées directement avec la syntaxe %{ENV_VAR}.

Les variables sont utiles, par exemple, dans ces cas:

 Lorsque les chaînes changent souvent dans les données de test. Avec les
variables, il vous suffit d'apporter ces modifications au même endroit.
 Lors de la création de données de test indépendantes du système et du
système d'exploitation. L'utilisation de variables au lieu de chaînes codées en
dur simplifie considérablement cette tâche (par exemple, ${RESOURCES}au
lieu de c:\resourcesou ${HOST} au lieu de 10.0.0.1:8080). Comme les
variables peuvent être définies à partir de la ligne de commande au démarrage des
tests, il est facile de modifier des variables spécifiques au système (par
exemple --variable HOST:10.0.0.2:1234 --variable
RESOURCES:/opt/resources). Cela facilite également les tests de localisation,
qui consistent souvent à exécuter les mêmes tests avec différentes chaînes.
 Lorsqu'il est nécessaire d'avoir des objets autres que des chaînes comme
arguments pour les mots-clés. Ceci n'est pas possible sans variables.
 Lorsque différents mots-clés, même dans des bibliothèques de test
différentes, doivent communiquer. Vous pouvez affecter une valeur de retour
d'un mot-clé à une variable et la transmettre comme argument à un autre.
 Lorsque les valeurs dans les données de test sont longues ou
compliquées. Par exemple, ${URL}est plus court
que http://long.domain.name:8080/path/to/service?foo=1&bar=2&zap=42.

Si une variable inexistante est utilisée dans les données de test, le mot clé qui
l'utilise échoue. Si la même syntaxe que celle utilisée pour les variables est requise
en tant que chaîne littérale, elle doit être précédée d'une barre oblique inverse comme
dans \${NAME}.

2.5.2 Types de variables

Différents types de variables sont expliqués dans cette section. La façon dont les
variables peuvent être créées est discutée dans les sections suivantes.

Les variables de la structure de robot, de même que les mots-clés, ne sont pas
sensibles à la casse, et les espaces et les traits de soulignement sont également
ignorés. Cependant, il est recommandé d'utiliser des majuscules avec des variables
globales (par exemple, ${PATH}ou ${TWO WORDS}) et des lettres minuscules avec des
variables uniquement disponibles dans certains cas de test ou mots-clés utilisateur
(par exemple ${my var}ou ${myVar}). Plus important encore, les cas doivent être
utilisés de manière cohérente.

Nom de la variable est constituée de l'identificateur de type variable ( $, @, &, %),

les accolades ( {, }) et nom de la variable réelle entre les accolades. Contrairement
à certains langages de programmation où une syntaxe de variable similaire est
utilisée, les accolades sont toujours obligatoires. Les noms de variables peuvent
fondamentalement avoir des caractères entre les accolades. Cependant, il est
recommandé de n'utiliser que des caractères alphabétiques de a à z, des nombres,
des traits de soulignement et des espaces, et même d'utiliser la syntaxe des variables
étendues .

Variables scalaires
Lorsque des variables scalaires sont utilisées dans les données de test, elles sont
remplacées par la valeur à laquelle elles sont affectées. Bien que les variables
scalaires soient le plus souvent utilisées pour les chaînes simples, vous pouvez leur
affecter des objets, y compris des listes. La syntaxe de la variable scalaire, par
exemple ${NAME}, devrait être familière à la plupart des utilisateurs, car elle est
également utilisée, par exemple, dans les scripts shell et le langage de
programmation Perl.

L'exemple ci-dessous illustre l'utilisation de variables scalaires. Si l'on suppose que

les variables ${GREET}et ${NAME}sont disponibles et affectés à
des chaînes Helloet world, respectivement, les deux cas de test exemple sont
équivalentes.
*** Cas de test ***
Les constantes
Journal Bonjour
Journal Bonjour, monde !!

Les variables
Log $ { GREET }
Log $ { GREET } , $ { NAME } !!

Lorsqu'une variable scalaire est utilisée comme valeur unique dans une cellule de
données de test, la variable scalaire est remplacée par la valeur dont elle dispose. La
valeur peut être n'importe quel objet. Lorsqu'une variable scalaire est utilisée dans
une cellule de test avec autre chose (chaînes constantes ou autres variables), sa
valeur est d'abord convertie en une chaîne Unicode, puis caténatée à celle qui se
trouve dans cette cellule. Convertir la valeur en chaîne signifie que la méthode de
l'objet __unicode__(en Python, avec __str__comme solution de secours)
ou toString(en Java) est appelée.

Remarque

Les valeurs de variables sont utilisées telles quelles sans conversions, également lors de la
transmission d’arguments à des mots-clés utilisant la syntaxe des arguments
nommés comme argname=${var}.

L'exemple ci-dessous montre la différence entre avoir une variable dans une cellule
seule ou avec un autre contenu. Tout d'abord, supposons que nous avons une
variable ${STR}définie sur une chaîne Hello, world!et ${OBJ}définie sur une
instance de l'objet Java suivant:
classe publique MyObj {

public String toString () {

return "Salut, tellus!" ;
}
}

Avec ces deux variables définies, nous disposons alors des données de test
suivantes:
*** Cas de test ***
Objets
KW 1 $ { STR }
KW 2 $ { OBJ } KW 3 J'ai dit " $ { STR } "

KW 4 Vous avez dit " $ { OBJ } "

Enfin, lorsque ces données de test sont exécutées, différents mots-clés reçoivent les
arguments comme expliqué ci-dessous:

 KW 1 obtient une chaîneHello, world!

 KW 2 obtient un objet stocké dans une variable${OBJ}
 KW 3 obtient une chaîneI said "Hello, world!"
 KW 4 reçoit une chaîneYou said "Hi, tellus!"

Remarque

La conversion de variables en Unicode échoue évidemment si la variable ne peut pas être

représentée comme Unicode. Cela peut se produire, par exemple, si vous essayez d’utiliser
des séquences d’octets comme arguments pour les mots-clés afin que vous puissiez regrouper
les valeurs comme si ${byte1}${byte2}. Une solution de contournement consiste à créer une
variable qui contient la valeur entière et à l'utiliser seule dans la cellule (par
exemple ${bytes}) car la valeur est utilisée telle quelle .

Variables de liste
Lorsqu'une variable est utilisée comme un scalaire ${EXAMPLE}, sa valeur sera
utilisée telle quelle. Si une valeur de variable est une liste ou une liste, il est
également possible d'utiliser une variable de liste comme @{EXAMPLE}. Dans ce cas,
des éléments de liste individuels sont passés en tant qu'arguments séparément. C'est
plus facile à expliquer avec un exemple. En supposant qu'une variable @{USER}a une
valeur ['robot', 'secret'], les deux cas de test suivants sont équivalents:
*** Cas de test ***
Les constantes
Login robot secret

Variable de liste
Login @ { USER }

Robot Framework stocke ses propres variables dans un stockage interne et permet
de les utiliser en tant que scalaires, listes ou dictionnaires. L'utilisation d'une
variable en tant que liste nécessite que sa valeur soit une liste Python ou un objet de
type liste. Robot Framework n'autorise pas l'utilisation de chaînes en tant que listes,
mais d'autres objets itérables tels que des tuples ou des dictionnaires sont acceptés.

Avant Robot Framework 2.9, les variables scalaires et de liste étaient stockées
séparément, mais il était possible d'utiliser des variables de liste sous forme de
scalaires et de variables scalaires sous forme de listes. Cela a causé beaucoup de
confusion quand il y avait accidentellement une variable scalaire et une variable de
liste avec le même nom mais une valeur différente.

Utilisation de variables de liste avec d'autres données

Il est possible d'utiliser des variables de liste avec d'autres arguments, y compris
d'autres variables de liste.
*** Cas de test ***
Exemple
Mot clé @ { LIST } plus d’ args
Mot clé $ { SCALAR } @ { LIST } constant
Mot clé @ { LISTE } @ { ANOTHER } @ { ONE MORE }

Si une variable de liste est utilisée dans une cellule avec d'autres données (chaînes
constantes ou autres variables), la valeur finale contiendra une représentation sous
forme de chaîne de la valeur de la variable. Le résultat final est donc exactement le
même que lorsque vous utilisez la variable comme un scalaire avec d'autres
données dans la même cellule.

Accéder à des éléments de liste individuels

Il est possible d'accéder à une certaine valeur d'une variable de liste avec la
syntaxe @{NAME}[index], où indexest l'index de la valeur sélectionnée. Les indices
commencent à zéro, les index négatifs peuvent être utilisés pour accéder aux
éléments depuis la fin, et essayer d'accéder à une valeur avec un index trop grand
provoque une erreur. Les indices sont automatiquement convertis en nombres
entiers et il est également possible d'utiliser des variables en tant qu'indices. Les
éléments de liste accédés de cette manière peuvent être utilisés de la même manière
que les variables scalaires.
*** Cas de test ***
Liste de variables
Login @ { USER } [ 0 ] @ { USER } [ 1 ] Le
titre devrait être le bienvenu @ { USER } [ 0 ] !

Index négatif
Log @ { LIST } [ -1 ]

Index comme variable

Log @ { LIST } [$ { INDEX }]

Utilisation de variables de liste avec des paramètres

Les variables de liste ne peuvent être utilisées qu'avec certains paramètres . Ils
peuvent être utilisés dans les arguments des bibliothèques importées et des fichiers
de variables, mais les noms de fichiers de bibliothèque et de variable ne peuvent
pas être des variables de liste. De même, avec les configurations et les démontages,
la variable de liste ne peut pas être utilisée comme nom du mot-clé, mais peut être
utilisée dans les arguments. Avec les paramètres liés aux balises, ils peuvent être
utilisés librement. L'utilisation de variables scalaires est possible dans les endroits
où les variables de liste ne sont pas prises en charge.
*** Paramètres ***
Library ExampleLibrary @ { LIB ARGS } # Cela fonctionne
Bibliothèque $ { LIBRARY } @ { LIB ARGS } # Cela fonctionne
Bibliothèque @ { NAME AND ARGS } # Cela ne
fonctionne pas Suite Setup Some Keyword @ { KW ARGS } # Cela
fonctionne

le programme d' installation de Suite $ { KEYWORD } @ { KW ARGS }

# Cela fonctionne
Suite Installation @ { KEYWORD } # Cela ne
fonctionne pas
Balises par défaut @ { TAGS } # Cela
fonctionne

Variables du dictionnaire
Comme indiqué ci-dessus, une variable contenant une liste peut être utilisée
comme variable de liste pour transmettre des éléments de liste à un mot-clé en tant
qu'arguments individuels. De même, une variable contenant un dictionnaire Python
ou un objet de type dictionnaire peut être utilisée comme variable de dictionnaire
comme &{EXAMPLE}. En pratique, cela signifie que des éléments individuels du
dictionnaire sont transmis en tant qu'arguments nommés au mot-clé. En supposant
qu'une variable &{USER}a une valeur {'name': 'robot', 'password': 'secret'}, les
deux cas de test suivants sont équivalents.
*** Cas de test ***
Les constantes
Nom de connexion = mot de passe du robot = secret

Variable Dict
Login & { USER }

Les variables de dictionnaire sont nouvelles dans Robot Framework 2.9.

Utiliser des variables de dictionnaire avec d'autres données

Il est possible d'utiliser des variables de dictionnaire avec d'autres arguments, y

compris d'autres variables de dictionnaire. Comme la syntaxe des arguments
nommés nécessite que les arguments de position soient avant l'argument nommé, les
dictionnaires ne peuvent être suivis que par des arguments nommés ou d'autres
dictionnaires.
*** Cas de test ***
Exemple
Mot-clé & { DICT } named = arg
Mot clé positionnel @ { LIST } & { DICT } Mot clé & { DICT } &
{ ANOTHER } & { ONE MORE }

Si une variable de dictionnaire est utilisée dans une cellule avec d'autres données
(chaînes constantes ou autres variables), la valeur finale contiendra une
représentation sous forme de chaîne de la valeur de la variable. Le résultat final est
donc exactement le même que lorsque vous utilisez la variable comme un scalaire
avec d'autres données dans la même cellule.

Accéder à des éléments de dictionnaire individuels

Il est possible d'accéder à une certaine valeur d'une variable de dictionnaire avec la
syntaxe &{NAME}[key], où keyest le nom de la valeur sélectionnée. Les clés sont
considérées comme des chaînes, mais les clés non-chaînes peuvent être utilisées
comme variables. Les valeurs de dictionnaire accessibles de cette manière peuvent
être utilisées de la même manière que les variables scalaires.

Si une clé est une chaîne, il est possible d'accéder à sa valeur en utilisant également
la syntaxe d'accès aux attributs ${NAME.key}. Voir Création de variables de
dictionnaire pour plus de détails sur cette syntaxe.

*** Cas de test ***

Article variable Dict
Login & { USER } [ name ] & { USER } [ mot de passe ]
Titre devrait être le bienvenu & { USER } [ name ] !

Clé comme variable

Log Many & { DICT } [$ { KEY }] & { DICT } [$ { 42 }]

Accès aux attributs

Login $ { USER.name } $ { USER.password } Le
titre devrait être bienvenu $ { USER.name } !

Utiliser des variables de dictionnaire avec des paramètres

Les variables du dictionnaire ne peuvent généralement pas être utilisées avec les
paramètres. Les seules exceptions sont les importations, les configurations et les
démontages où les dictionnaires peuvent être utilisés comme arguments.
*** Paramètres ***
Library ExempleLibrary & { LIB ARGS } Suite Setup Quelques mots clés
& { KW ARGS } named = arg

Variables d'environnement
Robot Framework permet d'utiliser des variables d'environnement dans les données
de test en utilisant la syntaxe %{ENV_VAR_NAME}. Ils sont limités aux valeurs de
chaîne.

Variables d'environnement définies dans le système d'exploitation avant l'exécution

du test sont disponibles pendant, et il est possible de créer de nouvelles avec le mot
- clé Set variable d' environnement ou de supprimer ceux qui existent déjà avec le
mot - clé Supprimer variable d' environnement , tous deux disponibles dans
la OperatingSystem bibliothèque. Les variables d'environnement étant globales, les
variables d'environnement définies dans un scénario de test peuvent être utilisées
dans d'autres scénarios de test exécutés après. Cependant, les modifications
apportées aux variables d'environnement ne sont pas efficaces après l'exécution du
test.
*** Cas de test ***
Variables Env
Journal Utilisateur actuel: % { USER } Exécuter % { JAVA_HOME } $ {
/ } javac

Propriétés du système Java

Lors de l'exécution de tests avec Jython, il est possible d'accéder aux propriétés du
système Java en utilisant la même syntaxe que les variables d'environnement . S'il existe
une variable d'environnement et une propriété système portant le même nom, la
variable d'environnement sera utilisée.
*** Cas de test ***
Propriétés du système
Log % { user.name } exécute des tests sur % { os.name }

2.5.3 Création de variables

Les variables peuvent surgir de différentes sources.

Table variable
Les sources de variables les plus courantes sont les tables de variables dans les
fichiers de scénarios de test et les fichiers de ressources . Les tables de variables sont
pratiques car elles permettent de créer des variables au même endroit que le reste
des données de test, et la syntaxe nécessaire est très simple. Leurs principaux
inconvénients sont que les valeurs sont toujours des chaînes et qu’elles ne peuvent
pas être créées dynamiquement. Si l'un de ces problèmes est un problème, les
fichiers variables peuvent être utilisés à la place.

Création de variables scalaires

L'attribution de variable la plus simple possible consiste à définir une chaîne dans
une variable scalaire. Cela se fait en donnant le nom de la variable (y compris ${})
dans la première colonne de la table Variable et la valeur dans la seconde. Si la
deuxième colonne est vide, une chaîne vide est définie comme valeur. Une variable
déjà définie peut également être utilisée dans la valeur.
*** Variables ***
$ { NAME } Framework Robot
$ { VERSION } 2.0
$ { ROBOT } $ { NAME } $ { VERSION }

Il est également possible, mais pas obligatoire, d'utiliser le signe égal =après le nom
de la variable pour rendre l'attribution des variables légèrement plus explicite.
*** Variables ***
$ { NAME } = Robot Framework
$ { VERSION } = 2.0

Si une variable scalaire a une valeur longue, elle peut être divisée en plusieurs
colonnes et lignes . Par défaut, les cellules sont regroupées en utilisant un espace,
mais cela peut être changé en ayant SEPARATOR=<sep>dans la première cellule.
*** Variables ***
$ { EXAMPLE } Cette valeur est jointe à un espace
$ { MULTILINE } SEPARATOR = \ n Première ligne
... Deuxième ligne Troisième ligne

Rejoindre des valeurs longues comme ci-dessus est une nouvelle fonctionnalité de
Robot Framework 2.9. Créer une variable scalaire avec plusieurs valeurs était une
erreur de syntaxe dans Robot Framework 2.8 et avec les versions antérieures, elle
créait une variable avec une valeur de liste.

Créer des variables de liste

La création de variables de liste est aussi simple que la création de variables

scalaires. Encore une fois, le nom de la variable se trouve dans la première colonne
de la table Variable et les valeurs dans les colonnes suivantes. Une variable de liste
peut avoir n'importe quel nombre de valeurs, à partir de zéro, et si plusieurs valeurs
sont nécessaires, elles peuvent être divisées en plusieurs lignes .
*** Variables ***
@ { NOMS } Matti Teppo
@ { NAMES2 } @ { NAMES } Seppo
@ { NOTHING }
@ { MANY }} un deux trois quatre
... cinq six sept

Créer des variables de dictionnaire

Les variables de dictionnaire peuvent être créées dans la table de variables de la

même manière que les variables de liste. La différence est que les éléments doivent
être créés en utilisant laname=valuesyntaxe ou les variables de dictionnaire
existantes. S'il existe plusieurs éléments portant le même nom, la dernière valeur
est prioritaire. Si un nom contient un signe égal littéral, il peut être échappé avec une
barre oblique inverse comme \=.
*** Variables ***
& { USER 1 } name = adresse Matti = xxx phone = 123
& { USER 2 } name = adresse Teppo = yyy phone = 456
& { MANY } en premier = 1 seconde = $ { 2 } $ { 3 } = tiers
& { EVEN MORE } & { MANY } en premier = écraser vide =
... = clé vide \ = ici = valeur

Les variables du dictionnaire ont deux propriétés supplémentaires par rapport aux
dictionnaires Python normaux. Tout d'abord, les valeurs de ces dictionnaires sont
accessibles comme des attributs, ce qui signifie qu'il est possible d'utiliser une
syntaxe de variable étendue comme ${VAR.key}. Cela ne fonctionne que si la clé est un
nom d'attribut valide et ne correspond à aucun attribut Python. Par exemple, la
valeur individuelle &{USER}[name]peut également être accédée
comme ${USER.name}(remarque $nécessaire dans ce contexte), mais
l'utilisation ${MANY.3}n'est pas possible.

Remarque

À partir de Robot Framework 3.0.3, les clés de variable du dictionnaire sont accessibles de
manière récursive ${VAR.nested.key}. Cela facilite l'utilisation des structures de données
imbriquées.
Une autre propriété spéciale des variables de dictionnaire est qu'elles sont
ordonnées. Cela signifie que si ces dictionnaires sont itérés, leurs éléments sont
toujours dans l’ordre dans lequel ils sont définis. Cela peut être utile si les
dictionnaires sont utilisés comme variables de liste avec des boucles for ou
autres. Lorsqu'un dictionnaire est utilisé comme variable de liste, la valeur réelle
contient des clés de dictionnaire. Par exemple, la @{MANY}variable aurait une
valeur ['first', 'second', 3].

Fichier variable
Les fichiers de variables constituent le mécanisme le plus puissant pour créer
différents types de variables. Il est possible d'affecter des variables à n'importe quel
objet les utilisant, et elles permettent également de créer des variables de manière
dynamique. La syntaxe du fichier de variables et l'utilisation de fichiers variables
sont expliquées dans la section Fichiers de ressources et de ressources .

Définition des variables en ligne de commande

Les variables peuvent être définies à partir de la ligne de commande, soit
individuellement avec l' option --variable (-v) , soit en utilisant un
fichier variable avec l' option --variablefile (-V) . Les variables
définies à partir de la ligne de commande sont globalement disponibles pour tous
les fichiers de données de test exécutés. Elles remplacent également les variables
possibles portant les mêmes noms dans la table Variable et dans les fichiers de
variables importés dans les données de test.

La syntaxe pour définir des variables individuelles est --variable name:

value , où nameest le nom de la variable sans ${}et valueest sa valeur. Plusieurs
variables peuvent être définies en utilisant cette option plusieurs fois. Seules les
variables scalaires peuvent être définies à l'aide de cette syntaxe et elles peuvent
uniquement obtenir des valeurs de chaîne. De nombreux caractères spéciaux sont
difficiles à représenter dans la ligne de commande, mais ils peuvent
être échappés avec l' option --escape .
--variable EXAMPLE: valeur
--variable HOST: localhost: 7272 --variable USER: robot
--variable ESCAPED: Qquotes_and_spacesQ --escape quot: Q --escape space: _

Dans les exemples ci-dessus, les variables sont définies pour que

 ${EXAMPLE} obtient la valeur value

 ${HOST}et ${USER}obtenir les valeurs localhost:7272etrobot
 ${ESCAPED} obtient la valeur "quotes and spaces"
La syntaxe de base pour utiliser des fichiers variables à partir de la ligne de
commande est --variablefile path / to / variables.py , et la
section Prendre des fichiers variables avec use a plus de détails. Les variables
réellement créées dépendent des variables présentes dans le fichier de variable
référencé.

Si les fichiers de variables et les variables individuelles sont tous deux fournis par
la ligne de commande, ces derniers ont une priorité plus élevée .

Valeurs de retour des mots-clés

Les valeurs de retour des mots-clés peuvent également être définies dans des
variables. Cela permet la communication entre différents mots-clés, même dans
différentes bibliothèques de tests.

Les variables définies de cette manière sont similaires aux autres variables, mais
elles ne sont disponibles que dans la portée locale où elles sont créées. Ainsi, il n'est
pas possible, par exemple, de définir une variable comme celle-ci dans un cas de
test et de l'utiliser dans une autre. En effet, en général, les scénarios de test
automatisés ne doivent pas dépendre les uns des autres, et la définition accidentelle
d’une variable utilisée ailleurs peut provoquer des erreurs de débogage
difficiles. S'il existe un réel besoin de définir une variable dans un scénario de test et
de l'utiliser dans un autre, il est possible d'utiliser les mots-clés intégrés, comme
expliqué dans la section suivante.

Affectation de variables scalaires

Toute valeur renvoyée par un mot clé peut être affectée à une variable
scalaire . Comme illustré par l'exemple ci-dessous, la syntaxe requise est très
simple:
*** Cas de test ***
De retour
$ { x } = Récupère un argument
Journal Nous avons $ { x } !

Dans l'exemple ci-dessus, la valeur renvoyée par le mot clé Get X est d'abord
définie dans la variable ${x}, puis utilisée par le mot clé Log . Avoir le signe
égal =après le nom de la variable n'est pas obligatoire, mais cela rend l'affectation
plus explicite. La création de variables locales comme celle-ci fonctionne à la fois
dans un scénario de test et au niveau du mot-clé utilisateur.

Notez que, bien qu'une valeur soit affectée à une variable scalaire, elle peut être
utilisée comme variable de liste si elle a une valeur de type liste et comme variable de
dictionnaire si elle a une valeur de type dictionnaire.

*** Cas de test ***

Exemple
$ { list } = Créer la liste premier deuxième tiers
Longueur doit être $ { list } 3
Log Many @ { list }

Assigner des variables de liste

Si un mot clé renvoie une liste ou un objet de type liste, il est possible de l’affecter
à une variable de liste :
*** Cas de test ***
Exemple
@ { list } = Créer la liste premier deuxième tiers
Longueur doit être $ { list } 3
Log Many @ { list }

Toutes les variables de la structure de robot étant stockées dans le même espace de
noms, il n'y a pas beaucoup de différence entre l'affectation d'une valeur à une
variable scalaire ou à une variable de liste. Cela peut être vu en comparant les deux
derniers exemples ci-dessus. Les principales différences sont les suivantes: lors de
la création d'une variable de liste, Robot Framework vérifie automatiquement que
la valeur est une liste ou une liste, et la valeur de la variable stockée sera une
nouvelle liste créée à partir de la valeur de retour. Lors de l'attribution d'une
variable scalaire, la valeur renvoyée n'est pas vérifiée et la valeur stockée sera
exactement le même objet que celui renvoyé.

Affectation de variables de dictionnaire

Si un mot clé renvoie un dictionnaire ou un objet similaire à un dictionnaire , il est

possible de l’affecter à une variable de dictionnaire :
*** Cas de test ***
Exemple
& { dict } = Créer d' abord le dictionnaire = 1 seconde = $ { 2 } $
{ 3 } = troisième
Longueur doit être $ { dict } 3
Faites quelque chose & { dict }
Log $ { dict.first }

Étant donné que toutes les variables de la structure de robot sont stockées dans le
même espace de noms, il serait également possible d'affecter un dictionnaire à une
variable scalaire et de l'utiliser ultérieurement comme dictionnaire si nécessaire. Il
y a cependant certains avantages à créer une variable de dictionnaire de manière
explicite. Tout d'abord, Robot Framework vérifie que la valeur renvoyée est
similaire à un dictionnaire ou à un dictionnaire, car elle vérifie que les variables de
liste ne peuvent obtenir qu'une valeur de type liste.

Un avantage plus important est que la valeur est convertie en un dictionnaire

spécial qu’elle utilise également lors de la création de variables de dictionnaire dans la
table de variables. Les valeurs de ces dictionnaires sont accessibles via l'accès aux
attributs, comme ${dict.first}dans l'exemple ci-dessus. Ces dictionnaires sont
également classés, mais si le dictionnaire d'origine n'a pas été commandé, l'ordre
résultant est arbitraire.

Affectation de plusieurs variables

Si un mot clé renvoie une liste ou un objet de type liste, il est possible d'affecter des
valeurs individuelles à plusieurs variables scalaires ou à des variables scalaires et à
une variable de liste.
*** Cas de test ***
Assigner plusieurs
$ { a } $ { b } $ { c } = Obtenir trois
$ { first } @ { rest } = Obtenir trois
@ { avant } $ { dernier } = obtenir trois
$ { begin } @ { middle } $ { end } = Obtenir trois

En supposant que le mot clé Get Three renvoie une liste [1, 2, 3], les variables
suivantes sont créées:

 ${a}, ${b}Et ${c}avec les valeurs 1, 2, et 3, respectivement.

 ${first}avec valeur 1et @{rest}avec valeur [2, 3].
 @{before}avec valeur [1, 2]et ${last}valeur 3.
 ${begin}avec valeur 1, @{middle}avec valeur [2]et $ {fin} avec valeur 3.

C'est une erreur si la liste renvoyée contient plus ou moins de valeurs qu'il y a de
variables scalaires à affecter. De plus, une seule variable de liste est autorisée et les
variables de dictionnaire ne peuvent être affectées que seules.

Le support pour l'attribution de plusieurs variables a été légèrement modifié dans

Robot Framework 2.9. Avant cela, une variable de liste n'était autorisée que comme
dernière variable assignée, mais de nos jours, elle peut être utilisée n'importe
où. De plus, il était possible de retourner plus de valeurs que les variables
scalaires. Dans ce cas, la dernière variable scalaire a été transformée comme par
magie en une liste contenant les valeurs supplémentaires.

Utilisation des mots-clés Set Test / Suite / Global Variable

La BuiltIn bibliothèque a des mots - clés Set Variable Test , Set Variable Suite et Set
variable globale qui peut être utilisé pour définir des variables dynamiquement lors
de l'exécution de test. Si une variable existe déjà dans la nouvelle étendue, sa valeur
sera écrasée, sinon une nouvelle variable sera créée.

Les variables définies avec le mot-clé Set Test Variable sont disponibles partout
dans la portée du scénario de test en cours d'exécution. Par exemple, si vous
définissez une variable dans un mot-clé utilisateur, elle est disponible au niveau du
scénario de test et dans tous les autres mots-clés utilisateur utilisés dans le test en
cours. Les autres cas de test ne verront pas les variables définies avec ce mot-clé.

Les variables définies avec le mot-clé Set Suite Variable sont disponibles partout
dans la portée de la suite de tests actuellement exécutée. Définir des variables avec
ce mot clé a donc le même effet que de les créer à l'aide de la table Variable du
fichier de données de test ou de les importer depuis des fichiers variables . Les autres
suites de tests, y compris les suites de tests enfants possibles, ne verront pas les
variables définies avec ce mot-clé.

Les variables définies avec le mot clé Set Global Variable sont globalement
disponibles dans tous les scénarios de test et suites exécutés après leur
définition. Définir des variables avec ce mot clé a donc le même effet que la création
à partir de la ligne de commande en utilisant les options --variable ou --
variablefile . Comme ce mot clé peut changer les variables partout, il doit
être utilisé avec précaution.

Remarque

Définissez les mots-clés Test / Suite / Global Variable définissez les variables nommées
directement dans la portée de la variable test, de la suite ou de la variable globale et ne
retournez rien. Par ailleurs, un autre mot-clé BuiltIn Set Variable définit des variables locales
à l'aide de valeurs de retour .

2.5.4 Variables intégrées

Robot Framework fournit des variables intégrées disponibles automatiquement.

Variables du système d'exploitation

Les variables intégrées liées au système d'exploitation facilitent le fonctionnement
des données de test indépendamment du système d'exploitation.

Variables intégrées liées au système d'exploitation disponibles

Variable Explication

$ {CURDIR} Un chemin absolu vers le répertoire où se trouve le fichier de données de

test. Cette variable est sensible à la casse.

$ Un chemin absolu vers le répertoire temporaire du système. Dans les systèmes de

{TEMPDIR} type UNIX, il s'agit généralement de / tmp et dans Windows c: \ Documents and
Settings \ <utilisateur> \ Local Settings \ Temp .

$ Un chemin absolu vers le répertoire à partir duquel l'exécution du test a été

{EXECDIR} lancée.
 Variables intégrées liées au système d'exploitation disponibles

Variable Explication

$ {/} Le séparateur de chemin de répertoire système. /dans les systèmes de type UNIX
et \ dans Windows.

$ {:} Le séparateur d'éléments du chemin système. :dans des systèmes de type UNIX
et ;dans Windows.

$ {\ n} Le séparateur de ligne du système. \ n dans les systèmes UNIX et \ r \

n sous Windows. Nouveau dans la version 2.7.5.
*** Cas de test ***
Exemple
Créer un fichier binaire $ { CURDIR } $ { / } input.data Du texte
ici $ { \ n } sur deux lignes
Définissez la variable d'environnement CLASSPATH $ { TEMPDIR } $ {
: } $ { CURDIR } $ { / } foo.jar

Les variables numériques

La syntaxe de la variable peut être utilisée pour créer à la fois des nombres entiers
et des nombres à virgule flottante, comme illustré dans l'exemple ci-dessous. Ceci
est utile quand un mot clé s'attend à obtenir un nombre réel, et non une chaîne qui
ressemble à un nombre, comme argument.
*** Cas de test ***
Exemple 1A
Connect example.com 80 # Connect obtient deux chaînes comme arguments

Exemple 1B
Connect example.com $ { 80 } # Connect obtient une chaîne et un
entier

Exemple 2
Do X $ { 3.14 } $ { -1e-4 } # Do X obtient des nombres à
virgule flottante de 3,14 à -0,0001

Il est possible de créer des entiers également à partir de valeurs binaires, octales et
hexadécimales en utilisant 0b, 0oet des 0xpréfixes, respectivement. La syntaxe n'est
pas sensible à la casse.
*** Cas de test ***
Exemple
Devrait être égal à $ { 0b1011 } $ { 11 }
devrait être égal à $ { 0o10 } $ { 8 } devrait être égal à $ { 0xff
} $ { 255 } devrait être égal à $ { 0B1010 } $ { 0XA }

Variables booléennes et aucune / null

De même, les valeurs booléennes et Python Noneet Java nullpeuvent être créées en
utilisant la syntaxe de la variable de la même manière que les nombres.
*** Cas de test ***
Booléen
Définir le statut $ { true } # Définir le statut
obtient un booléen true en tant qu'argument
Créer quelque chose $ { false } # Create Y obtient une chaîne et un
booléen false

Aucun
Do XYZ $ { None } # Est-ce que XYZ obtient
Python None en argument

Nul
$ { ret } = Valeur obtenue arg # Vérification que Get Value renvoie
Java null Devrait être égal à $ { ret } $ { null }

Ces variables sont insensibles à la casse, par exemple ${True}et ${true}sont

équivalentes. En outre, ${None}et ${null}sont des synonymes, car lorsque vous
exécutez des tests sur l'interpréteur Jython, Jython convertit
automatiquement Noneet nullau format approprié lorsque cela est nécessaire.

Espace et variables vides

Il est possible de créer des espaces et des chaînes vides à l'aide de
variables ${SPACE}et ${EMPTY}, respectivement. Ces variables sont utiles, par
exemple, lorsqu'il serait nécessaire d' échapper des espaces ou des cellules vides avec
une barre oblique inverse. Si plus d'un espace est nécessaire, il est possible
d'utiliser la syntaxe de la variable étendue comme ${SPACE * 5}. Dans l'exemple
suivant, le mot-clé Should Be Equal reçoit des arguments identiques, mais ceux
utilisant des variables sont plus faciles à comprendre que ceux utilisant des barres
obliques inverses.
*** Cas de test ***
Un espace
Devrait être égal $ { SPACE } \ \

Quatre espaces
Devrait être égal $ { ESPACE * 4 } \ \ \ \ \

Dix espaces
Devrait être égal $ { ESPACE * 10 } \ \ \ \ \ \ \ \ \ \

Espace coté
Devrait être égal " $ { SPACE } " ""

Espaces cotés
Devrait être égal " $ { SPACE * 2 } " "\"

Vide
Devrait être égal $ { EMPTY } \
Il existe également une variable de liste vide @{EMPTY}et une variable de
dictionnaire vide &{EMPTY}. Comme ils n'ont pas de contenu, ils disparaissent
lorsqu'ils sont utilisés quelque part dans les données de test. Ils sont utiles, par
exemple, avec les modèles de test lorsque le mot-clé template est utilisé sans
arguments ou lors du remplacement de variables de liste ou de dictionnaire dans
différentes étendues. Modifier la valeur de @{EMPTY}ou &{EMPTY}n'est pas possible.
*** Cas de test ***
Modèle
[ Template ] Un mot clé
@ { EMPTY }

Passer outre
Définissez la variable globale @ { LIST } @ { EMPTY }
Définissez la variable Suite & { DICT } & { EMPTY }

Remarque

@{EMPTY}est nouveau dans Robot Framework 2.7.4 et &{EMPTY}dans Robot Framework 2.9.

Variables automatiques
Certaines variables automatiques peuvent également être utilisées dans les données
de test. Ces variables peuvent avoir des valeurs différentes lors de l'exécution du
test et certaines d'entre elles ne sont même pas disponibles tout le temps. La
modification de la valeur de ces variables n'affecte pas les valeurs d'origine, mais
certaines valeurs peuvent être modifiées dynamiquement à l'aide de mots-clés de
la bibliothèque BuiltIn .

Variables automatiques disponibles

Variable Explication Disponible

$ {NOM DU TEST} Le nom du test élémentaire en cours. Cas de test

@ {TAG TEST} Contient les balises du test élémentaire actuel dans Cas de test
l'ordre alphabétique. Peut être modifié
dynamiquement à l'aide des mots clés Définir des
balises et Supprimer des balises .

$ {DOCUMENTATION La documentation du cas de test actuel. Peut être Cas de test

DU TEST} défini dynamiquement en utilisant le mot-clé Set Test
Documentation .Nouveau dans Robot Framework 2.7.

$ {STATUT DE TEST} Le statut du test élémentaire en cours, PASS ou FAIL. Test de

démontage

$ {MESSAGE DE TEST} Le message du test élémentaire en cours. Test de

démontage

$ {PREV NOM DU Le nom du scénario de test précédent ou une chaîne Partout

TEST} vide si aucun test n'a encore été exécuté.
Variables automatiques disponibles

Variable Explication Disponible

$ {STATUT DU PRET Le statut du scénario de test précédent: soit PASS, Partout

TEST} FAIL, soit une chaîne vide si aucun test n'a été
exécuté.

$ {MESSAGE D'ESSAI Le message d'erreur possible du cas de test précédent. Partout

PRECEDENT}

$ {NOM DE LA SUITE} Le nom complet de la suite de tests actuelle. Partout

$ {SOURCE DE SUITE} Un chemin absolu vers le fichier ou le répertoire de la Partout

suite.

$ {DOCUMENTATION La documentation de la suite de tests actuelle. Peut Partout

SUITE} être défini dynamiquement en utilisant le mot-clé Set
Suite Documentation .Nouveau dans Robot
Framework 2.7.

& {SUITE Les métadonnées gratuites de la suite de tests Partout

METADATA} actuelle. Peut être défini avec le mot-clé Set Suite
Metadata . Nouveau dans Robot Framework 2.7.4.

$ {ÉTAT DE LA SUITE} Le statut de la suite de tests actuelle, PASS ou FAIL. Démontage

de la suite

$ {MESSAGE SUITE} Le message complet de la suite de tests actuelle, y Démontage

compris les statistiques. de la suite

$ {STATUT DU MOT- Le statut du mot-clé actuel, soit PASS ou Mot-clé

CLÉ} FAIL. Nouveau dans Robot Framework 2.7 utilisateur

$ {MESSAGE DU MOT- Le message d'erreur possible du mot clé en Mot-clé

CLÉ} cours. Nouveau dans Robot Framework 2.7. utilisateur

$ {LOG LEVEL} Actuel niveau de journalisation . Nouveau dans Robot Partout

Framework 2.8.

$ {FICHIER DE Un chemin absolu vers le fichier de sortie . Partout

SORTIE}

$ {LOG FILE} Chemin d'accès absolu au fichier journal ou à la Partout

chaîne NONE lorsqu'aucun fichier journal n'est créé.

$ {REPORT FILE} Chemin d'accès absolu au fichier de rapport ou à la Partout

chaîne NONE lorsqu'aucun rapport n'est créé.

$ {DEBUG FILE} Chemin d'accès absolu au fichier de débogage ou à la Partout

chaîne NONE lorsqu'aucun fichier de débogage n'est
créé.

$ {OUTPUT DIR} Un chemin absolu vers le répertoire de sortie . Partout

Variables liées à la Suite ${SUITE SOURCE}, ${SUITE NAME}, ${SUITE
DOCUMENTATION}et &{SUITE METADATA}sont déjà disponibles lorsque les bibliothèques
de test et les fichiers variables sont importés, sauf cadre Robot 2.8 et 2.8.1 où ce
soutien a été brisé. Les variables possibles dans ces variables automatiques ne sont
pas encore résolues au moment de l'importation.

2.5.5 Priorités variables et portées

Les variables provenant de différentes sources ont des priorités différentes et sont
disponibles dans des domaines différents.

Priorités variables
Variables depuis la ligne de commande

Les variables définies dans la ligne de commande ont la priorité la plus élevée de toutes
les variables pouvant être définies avant le démarrage de l'exécution du test. Ils
remplacent les variables possibles créées dans les tables de variables dans les
fichiers de scénarios de test, ainsi que dans les fichiers de ressources et de variables
importés dans les données de test.

Les variables définies individuellement ( option --variable ) remplacent les

variables définies à l'aide des fichiers de variables ( option --variablefile ). Si
vous spécifiez la même variable individuelle plusieurs fois, la dernière spécifiée
remplacera les précédentes. Cela permet de définir des valeurs par défaut pour les
variables d'un script de démarrage et de les remplacer à partir de la ligne de
commande. Notez cependant que si plusieurs fichiers de variables ont les mêmes
variables, celles du fichier spécifié en premier ont la priorité la plus élevée.

Table de variables dans un fichier de cas de test

Les variables créées à l'aide de la table Variable dans un fichier de scénario de test
sont disponibles pour tous les scénarios de test dans ce fichier. Ces variables
remplacent les variables possibles avec les mêmes noms dans les fichiers de
ressources et de variables importés.

Les variables créées dans les tables de variables sont disponibles dans toutes les
autres tables du fichier où elles ont été créées. Cela signifie qu'ils peuvent
également être utilisés dans la table Setting, par exemple, pour importer plus de
variables à partir de fichiers de ressources et de variables.

Ressource importée et fichiers variables

Les variables importées à partir des fichiers de ressources et de variables ont la priorité
la plus faible de toutes les variables créées dans les données de test. Les variables
des fichiers de ressources et des fichiers de variables ont la même priorité. Si
plusieurs fichiers de ressources et / ou variables ont les mêmes variables, celles du
fichier importé en premier sont utilisées.

Si un fichier de ressources importe des fichiers de ressources ou des fichiers de

variables, les variables de sa propre table de variables ont une priorité plus élevée
que les variables qu'il importe. Toutes ces variables sont disponibles pour les
fichiers qui importent ce fichier de ressources.

Notez que les variables importées à partir des fichiers de ressources et de variables
ne sont pas disponibles dans la table Variable du fichier qui les importe. Cela est dû
au traitement de la table Variable avant la table Setting où les fichiers de ressources
et les fichiers de variables sont importés.

Variables définies lors de l'exécution du test

Les variables définies lors de l'exécution du test à l'aide de valeurs renvoyées par des
mots clés ou à l' aide des mots clés Définir test / Suite / Variable globale remplacent
toujours les variables existantes possibles dans la portée où elles sont définies. En
un sens, ils ont donc la plus haute priorité, mais en revanche ils n'affectent pas les
variables en dehors du champ d'application défini.

Variables intégrées

Les variables intégrées aiment ${TEMPDIR}et ${TEST_NAME} ont la plus haute priorité de
toutes les variables. Ils ne peuvent pas être remplacés à l'aide de la table Variable
ou de la ligne de commande, mais ils peuvent même être réinitialisés pendant
l'exécution du test. Une exception à cette règle sont les variables numériques , qui
sont résolues dynamiquement si aucune variable n’est trouvée autrement. Ils
peuvent donc être ignorés, mais c'est généralement une mauvaise idée. En outre,
il ${CURDIR} est spécial car il est déjà remplacé pendant le temps de traitement des
données de test.

Étendues variables
Selon où et comment ils sont créés, les variables peuvent avoir une suite de tests
globale, un scénario de test ou une portée locale.

Portée globale

Les variables globales sont disponibles partout dans les données de test. Ces
variables sont normalement définies à partir de la ligne de commande avec les options -
-variable et --variablefile , mais il est également possible de créer de
nouvelles variables globales ou de changer celles existantes avec le mot-
clé BuiltIn Définir une variable globale dans les données de test. De plus,
les variables intégrées sont également globales.

Il est recommandé d'utiliser des majuscules avec toutes les variables globales.

Portée de la suite de tests

Les variables avec la portée de la suite de tests sont disponibles partout dans la
suite de tests où elles sont définies ou importées. Ils peuvent être créés dans des
tables de variables, importés à partir de fichiers de ressources et de variables , ou
définis lors de l'exécution du test à l'aide du mot-clé BuiltIn Définir une variable de
suite .

La portée de la suite de tests n'est pas récursive , ce qui signifie que les variables
disponibles dans une suite de tests de niveau supérieur ne sont pas disponibles dans
les suites de niveau inférieur. Si nécessaire, des fichiers de ressources et de
variables peuvent être utilisés pour partager des variables.

Comme ces variables peuvent être considérées comme globales dans la suite de
tests où elles sont utilisées, il est recommandé d’utiliser également des lettres
majuscules.

Portée du cas de test

Les variables avec la portée du scénario de test sont visibles dans un scénario de
test et dans tous les mots-clés utilisateur utilisés par le test. Au départ, il n'y a pas
de variables dans cette étendue, mais il est possible de les créer en utilisant le mot-
clé BuiltIn Définir la variable de test n'importe où dans un scénario de test.

Les variables de la portée du test élémentaire sont également globales. Il est donc
généralement recommandé d'utiliser des lettres majuscules avec eux.

Portée locale

Les scénarios de test et les mots-clés utilisateur ont une portée de variable locale
qui n'est pas vue par d'autres tests ou mots-clés. Les variables locales peuvent être
créées en utilisant les valeurs de retour des mots-clés exécutés et les mots-clés des
utilisateurs les utilisent également comme arguments .

Il est recommandé d'utiliser des lettres minuscules avec des variables locales.

Remarque

Avant Robot Framework 2.9, les variables de la portée locale étaient divisées en mots-clés
utilisateur de niveau inférieur . Cela n'a jamais été une fonctionnalité prévue et les variables
doivent être définies ou transmises explicitement également avec les versions antérieures.
2.5.6 Fonctions de variables avancées
Syntaxe de variable étendue
La syntaxe des variables étendues permet d'accéder aux attributs d'un objet affecté
à une variable (par exemple ${object.attribute}) et même d'appeler ses méthodes
(par exemple ${obj.getName()}). Il fonctionne à la fois avec les variables scalaires
et les variables de liste, mais est principalement utile avec les anciennes

La syntaxe des variables étendues est une fonctionnalité puissante, mais elle doit
être utilisée avec précaution. L'accès aux attributs n'est normalement pas un
problème, au contraire, car une variable contenant un objet avec plusieurs attributs
est souvent préférable à plusieurs variables. D'autre part, les méthodes d'appel, en
particulier lorsqu'elles sont utilisées avec des arguments, peuvent rendre les
données de test assez compliquées à comprendre. Si cela se produit, il est
recommandé de déplacer le code dans une bibliothèque de test.

Les utilisations les plus courantes de la syntaxe des variables étendues sont
illustrées dans l'exemple ci-dessous. Supposons d'abord que nous avons le fichier de
variables et le cas de test suivants:

classe MyObject :

def __init__ ( self , name ):

self . nom = nom

def eat ( self , what ):

return ' % s eats % s ' % ( self . nom , quoi )

def __str__ ( self ):

retourne soi-même . prénom

OBJECT = MyObject ( 'Robot' )

DICTIONARY = { 1 : 'one' , 2 : 'two' , 3 : 'three' }
*** Cas de test ***
Exemple
KW 1 $ { OBJECT.name }
KW 2 $ { OBJECT.eat ('Concombre') } KW 3 $ { DICTIONARY [2] }

Lorsque ces données de test sont exécutées, les mots-clés reçoivent les arguments
suivants:

 KW 1 obtient la chaîneRobot
 KW 2 obtient la chaîneRobot eats Cucumber
 KW 3 obtient la chaînetwo

La syntaxe de la variable étendue est évaluée dans l'ordre suivant:

 1. La variable est recherchée en utilisant le nom complet de la variable. La
syntaxe de la variable étendue est évaluée uniquement si aucune variable
correspondante n'est trouvée.
2. Le nom de la variable de base est créé. Le corps du nom comprend tous les
caractères après l'ouverture {jusqu'à la première occurrence d'un caractère
qui n'est pas un caractère alphanumérique ou un espace. Par exemple, les
variables de base de ${OBJECT.name} et ${DICTIONARY[2]})
sont OBJECTet DICTIONARY, respectivement.
3. Une variable correspondant au corps est recherchée. S'il n'y a pas de
correspondance, une exception est déclenchée et le scénario de test échoue.
4. L'expression à l'intérieur des accolades est évaluée comme une expression
Python, de sorte que le nom de la variable de base est remplacé par sa
valeur. Si l'évaluation échoue en raison d'une syntaxe non valide ou que
l'attribut demandé n'existe pas, une exception est déclenchée et le test
échoue.
5. Toute la variable étendue est remplacée par la valeur renvoyée par
l'évaluation.

Si l'objet utilisé est implémenté avec Java, la syntaxe de la variable étendue vous
permet d'accéder aux attributs en utilisant les propriétés de bean. Essentiellement,
cela signifie que si vous avez un objet avec la getName méthode définie dans une
variable ${OBJ}, la syntaxe ${OBJ.name}est équivalente mais plus claire
que ${OBJ.getName()}. L'objet Python utilisé dans l'exemple précédent pourrait
donc être remplacé par l'implémentation Java suivante:
classe publique MyObject :

nom de chaîne privé ;

public MyObject ( nom de chaîne ) { nom = nom ; }

public String getName () {

return name ;
}

public String eat ( String what ) {

retourne le nom + "mange" + quoi ;
}

public String toString () {

return name ;
}
}

De nombreux objets Python standard, y compris les chaînes et les nombres, ont des
méthodes qui peuvent être utilisées avec la syntaxe de la variable étendue de
manière explicite ou explicite. Parfois, cela peut s'avérer très utile et réduire le
besoin de définir des variables temporaires, mais il est également facile de les
utiliser de manière excessive et de créer des données de test vraiment cryptées. Les
exemples suivants montrent quelques très bons usages.
*** Cas de test ***
Chaîne
$ { string } = Définir la variable abc
Log $ { string.upper () } # Logs 'ABC'
Log $ { string * 2 } # Logs 'abcabc'

Nombre
$ { number } = Définir la variable $ { -2 }
Log $ { number * 10 } # Logs -20 Log $ { number .__ abs __
() } # Logs 2

Notez que même si le code Python normal abs(number)est

recommandé number.__abs__(), l'utilisation ${abs(number)}ne fonctionne pas. C'est
parce que le nom de la variable doit être au début de la syntaxe
étendue. L'utilisation de __xxx__ méthodes comme celles-ci dans les données de
test est déjà un peu discutable, et il est normalement préférable de déplacer ce type
de logique dans les bibliothèques de test.

La syntaxe des variables étendues fonctionne également dans le contexte

des variables de liste . Si, par exemple, un objet affecté à une variable ${EXTENDED}a
un attribut attributequi contient une liste en tant que valeur, il peut être utilisé
comme variable de liste @{EXTENDED.attribute}.

Affectation de variables étendue

À partir de Robot Framework 2.7, il est possible de définir des attributs d'objets
stockés sur des variables scalaires à l'aide de valeurs de retour de mots clés et d'une
variante de la syntaxe de la variable étendue . En supposant que nous ayons une
variable à ${OBJECT}partir des exemples précédents, des attributs peuvent être
définis comme dans l'exemple ci-dessous.
*** Cas de test ***
Exemple
$ { OBJECT.name } = Définir la variable Nouveau nom
$ { OBJECT.new_attr } = Définir la variable Nouvel attribut

La syntaxe d'attribution des variables étendues est évaluée à l'aide des règles
suivantes:

1. La variable affectée doit être une variable scalaire et avoir au moins un

point. Sinon, la syntaxe d'affectation étendue n'est pas utilisée et la variable
est affectée normalement.
 2. S'il existe une variable avec le nom complet (par
exemple ${OBJECT.name}dans l'exemple ci-dessus), cette variable se verra
attribuer une nouvelle valeur et la syntaxe étendue n'est pas utilisée.
3. Le nom de la variable de base est créé. Le corps du nom est constitué de tous
les caractères entre l’ouverture ${et le dernier point, par
exemple, OBJECTdedans ${OBJECT.name} et foo.bardedans ${foo.bar.zap}. C
omme l'illustre le deuxième exemple, le nom de base peut contenir une
syntaxe de variable étendue normale.
4. Le nom de l'attribut à définir est créé en prenant tous les caractères entre le
dernier point et la fermeture }, par exemple, namedans ${OBJECT.name}. Si le
nom ne commence pas par une lettre ou un trait de soulignement et ne
contient que ces caractères et nombres, l'attribut est considéré comme non
valide et la syntaxe étendue n'est pas utilisée. Une nouvelle variable avec le
nom complet est créée à la place.
5. Une variable correspondant au nom de base est recherchée. Si aucune
variable n'est trouvée, la syntaxe étendue n'est pas utilisée et une nouvelle
variable est créée à l'aide du nom complet de la variable.
6. Si la variable trouvée est une chaîne ou un nombre, la syntaxe étendue est
ignorée et une nouvelle variable créée avec le nom complet. Ceci est fait
parce que vous ne pouvez pas ajouter de nouveaux attributs aux chaînes ou
aux nombres Python, de sorte que la nouvelle syntaxe est également moins
incompatible avec les versions antérieures.
7. Si toutes les règles précédentes correspondent, l'attribut est défini sur la
variable de base. Si la configuration échoue pour une raison quelconque, une
exception est déclenchée et le test échoue.

Remarque

Contrairement à l'affectation de variables utilisant normalement les valeurs de retour des

mots - clés , les modifications apportées aux variables à l'aide de la syntaxe d'affectation
étendue ne sont pas limitées à l'étendue actuelle. Comme aucune nouvelle variable n'est créée
mais que l'état d'une variable existante est modifié, tous les tests et mots-clés qui voient cette
variable verront également les modifications.

Variables à l'intérieur des variables

Les variables sont également autorisées dans les variables, et lorsque cette syntaxe
est utilisée, les variables sont résolues de l'intérieur. Par exemple, si vous avez une
variable ${var${x}}, elle ${x}est résolue en premier. Si elle a la valeur name, la
valeur finale est alors la valeur de la variable ${varname}. Il peut y avoir plusieurs
variables imbriquées, mais la résolution du problème le plus externe échoue si l'une
d'entre elles n'existe pas.
Dans l'exemple ci-dessous, Do X obtient la valeur ${JOHN HOME} ou ${JANE HOME},
selon que Get Name retourne johnou jane. S'il renvoie quelque chose d'autre, la
résolution ${${name} HOME}échoue.
*** Variables ***
$ { JOHN HOME } / home / john
$ { JANE HOME } / home / jane

*** Cas de test ***

Exemple
$ { name } = Récupère le nom
Do X $ {$ { name } HOME }

2.6 Création de mots-clés utilisateur

Les tables de mots-clés sont utilisées pour créer de nouveaux mots-clés de niveau
supérieur en combinant des mots-clés existants. Ces mots-clés sont appelés mots-
clés utilisateur pour les différencier des mots - clés de bibliothèque de niveau le
plus bas implémentés dans les bibliothèques de tests. La syntaxe de création des
mots-clés utilisateur est très proche de la syntaxe de création de cas de test, ce qui
facilite son apprentissage.

 2.6.1 Syntaxe du mot-clé utilisateur

o Syntaxe de base
o Paramètres dans le tableau des mots clés
 2.6.2 Nom d'utilisateur et documentation
 2.6.3 Tags de mot-clé utilisateur
 2.6.4 Arguments relatifs aux mots-clés utilisateur
o Arguments positionnels
o Valeurs par défaut avec les mots-clés de l'utilisateur
o Varargs avec des mots-clés utilisateur
o Kwargs avec des mots-clés d'utilisateur
 2.6.5 Incorporation d’arguments au nom du mot clé
o Syntaxe de base
o Les arguments incorporés correspondant trop
o Utilisation d'expressions régulières personnalisées
o Exemple de développement axé sur le comportement
 2.6.6 Valeurs de retour du mot-clé utilisateur
o Utiliser le réglage [Retour]
o Utiliser des mots-clés spéciaux pour retourner
 2.6.7 Décryptage du mot-clé utilisateur

2.6.1 Syntaxe du mot-clé utilisateur

Syntaxe de base
À bien des égards, la syntaxe globale du mot-clé utilisateur est identique à celle
du scénario de test . Les mots-clés utilisateur sont créés dans des tables de mots-clés
qui diffèrent des tables de tests uniquement par le nom utilisé pour les
identifier. Les noms de mots-clés utilisateur se trouvent dans la première colonne
de la même manière que les noms de cas de test. Les mots-clés utilisateur sont
également créés à partir de mots-clés, à partir de mots-clés dans des bibliothèques
de tests ou d'autres mots-clés utilisateur. Les noms de mot-clé se trouvent
normalement dans la deuxième colonne, mais lors de la définition des variables à
partir des valeurs renvoyées par mot-clé, elles figurent dans les colonnes suivantes.
*** Mots clés ***
Ouvrir la page de connexion
Ouvrez le navigateur http: //host/login.html
Le titre devrait être la page de connexion

Le titre devrait commencer par

[ Arguments ] $ { attendu }
$ { title } = Récupérer le titre
Devrait commencer avec $ { title } $ { expected }

La plupart des mots-clés utilisateur prennent quelques arguments. Cette

fonctionnalité importante est déjà utilisée dans le deuxième exemple ci-dessus, et
elle est expliquée en détail plus loin dans cette section , tout comme les valeurs de retour
de mot-clé utilisateur .

Les mots-clés utilisateur peuvent être créés dans des fichiers de scénarios de test , des
fichiers de ressources et des fichiers d'initialisation de suites de tests . Les mots-clés créés
dans les fichiers de ressources sont disponibles pour les fichiers qui les utilisent,
tandis que les autres mots-clés ne sont disponibles que dans les fichiers où ils sont
créés.

Paramètres dans le tableau des mots clés

Les mots-clés utilisateur peuvent avoir des paramètres similaires à ceux des cas de
test et ils ont la même syntaxe entre crochets qui les sépare des noms de mots-
clés. Tous les paramètres disponibles sont répertoriés ci-dessous et expliqués plus
loin dans cette section.

[Documentation]
Utilisé pour définir une documentation de mot-clé utilisateur .
[Mots clés]
Définit les balises pour le mot clé.
[Arguments]
Spécifie les arguments de mot-clé utilisateur .
[Revenir]
Spécifie les valeurs de retour du mot clé utilisateur .
[Abattre]
Spécifiez le démontage du mot-clé utilisateur .
[Temps libre]
Définit le délai d'expiration du mot clé utilisateur . Les délais d'attente sont discutés
dans une section qui leur est propre.

2.6.2 Nom d'utilisateur et documentation

Le nom de mot-clé de l'utilisateur est défini dans la première colonne du tableau de
mots-clés de l'utilisateur. Bien sûr, le nom doit être descriptif et il est acceptable
d'avoir des noms de mots-clés assez longs. En fait, lors de la création de cas de test
semblables à une cas d'utilisation, les mots clés de plus haut niveau sont souvent
formulés sous forme de phrases ou même de paragraphes.

Les mots-clés utilisateur peuvent avoir une documentation définie avec

le paramètre [Documentation] , exactement comme la documentation du scénario
de test . Ce paramètre documente le mot-clé utilisateur dans les données de test. Il
est également montré dans une documentation de mots-clés plus formelle, que
l' outil Libdoc peut créer à partir de fichiers de ressources . Enfin, la première ligne de
la documentation est présentée sous forme de documentation par mot-clé dans les
journaux de test .

Parfois, les mots-clés doivent être supprimés, remplacés par de nouveaux, ou

déconseillés pour d'autres raisons. Les mots-clés utilisateur peuvent être marqués
comme obsolètes en démarrant la documentation avec *DEPRECATED*, ce qui
provoquera un avertissement lorsque le mot-clé est utilisé. Pour plus
d'informations, voir la section Déprécier les mots clés .

2.6.3 Tags de mot-clé utilisateur

À partir de Robot Framework 2.9, les mots-clés peuvent également comporter des
balises. Les balises de mots-clés utilisateur peuvent être définies avec le
paramètre [Balises] de la même manière que les balises de scénario de test , mais
le paramètre Forcer les balises et les balises par défaut ne les affecte pas. De plus,
les étiquettes de mots-clés peuvent être spécifiées sur la dernière ligne de la
documentation avec un Tags:préfixe et séparées par une virgule. Par exemple,
suivre deux mots-clés obtiendrait les trois mêmes balises.
*** Mots clés ***
Paramètres tags en utilisant un paramètre séparé
[ Tags ] mes beaux tags
Pas d'opération

Balises de paramètres à l'aide de la documentation

[ Documentation ] J'ai de la documentation. Et ma documentation a
des balises.
... Tags: mon, bien, tags
Pas d'opération
Les étiquettes de mots-clés sont affichées dans les journaux et dans la
documentation générée par Libdoc , où les mots-clés peuvent également être
recherchés en fonction de balises. Les options de ligne de commande --
removekeywords et --flattenkeywords prennent également en charge la sélection de
mots-clés par balise, et de nouvelles utilisations pour les balises de mots-clés sont
éventuellement ajoutées dans les versions ultérieures.

De même que pour les balises de test élémentaire , les étiquettes de mots-clés
utilisateur robot-et les robot:préfixes sont réservés aux fonctions spéciales par
Robot Framework lui-même. Les utilisateurs ne doivent donc utiliser aucune balise
avec ces préfixes, à moins d'activer la fonctionnalité spéciale.

2.6.4 Arguments relatifs aux mots-clés utilisateur

La plupart des mots-clés utilisateur doivent prendre en compte certains
arguments. La syntaxe pour les spécifier est probablement la fonctionnalité la plus
compliquée normalement requise avec Robot Framework, mais même celle-ci est
relativement facile, en particulier dans la plupart des cas. Les arguments sont
normalement spécifiés avec le paramètre [Arguments] , et les noms d'argument
utilisent la même syntaxe que les variables , par exemple ${arg}.

Arguments positionnels
La manière la plus simple de spécifier des arguments (à part de ne pas les avoir du
tout) consiste à utiliser uniquement des arguments de position. Dans la plupart des
cas, c'est tout ce dont vous avez besoin.

La syntaxe est telle que le paramètre [Arguments] est indiqué en premier et que les
noms d’argument sont définis dans les cellules suivantes. Chaque argument est
dans sa propre cellule, en utilisant la même syntaxe qu'avec les variables. Le mot-
clé doit être utilisé avec autant d'arguments qu'il y a de noms d'argument dans sa
signature. Les noms d'argument réels n'ont pas d'importance pour le cadre, mais du
point de vue des utilisateurs, ils devraient être aussi descriptifs que possible. Il est
recommandé d'utiliser des lettres minuscules dans les noms de variables, soit sous
forme ${my_arg}, ${my arg}soit ${myArg}.
*** Mots clés ***
Un argument
[ Arguments ] $ { arg_name }
Log Argument obtenu $ { arg_name }

Trois arguments
[ Arguments ] $ { arg1 } $ { arg2 } $ { arg3 }
Log 1er argument: $ { arg1 } Log 2ème argument: $ { arg2 } Log 3ème
argument: $ { arg3 }
Valeurs par défaut avec les mots-clés de l'utilisateur
Lors de la création de mots-clés utilisateur, les arguments positionnels sont
suffisants dans la plupart des situations. Il est cependant parfois utile que les mots-
clés contiennent des valeurs par défautpour certains ou tous leurs arguments. Les
mots-clés utilisateur prennent également en charge les valeurs par défaut, et la
nouvelle syntaxe nécessaire n’ajoute pas beaucoup à la syntaxe de base déjà
décrite.

En bref, les valeurs par défaut sont ajoutées aux arguments, de sorte qu’il ya
d’abord le signe égal ( =), puis la valeur, par exemple ${arg}=default. Il peut y
avoir beaucoup d’arguments avec des paramètres par défaut, mais ils doivent tous
être donnés après les arguments positionnels normaux. La valeur par défaut peut
contenir une variable créée sur test, suite ou portée globale , mais les variables locales
du mot clé exécuteur ne peuvent pas être utilisées. À partir de Robot Framework
3.0, la valeur par défaut peut également être définie en fonction des arguments
antérieurs acceptés par le mot clé.

Remarque

La syntaxe des valeurs par défaut est sensible à l'espace. Les espaces avant le =signe ne sont
pas autorisés et les espaces possibles après lui sont considérés comme faisant partie de la
valeur par défaut elle-même.

*** Mots clés ***

Un argument avec une valeur par défaut
[ Arguments ] $ { arg } = valeur par défaut
[ Documentation ] Ce mot clé prend 0-1 arguments
Log Got argument $ { arg }

Deux arguments avec des valeurs par défaut

[ Arguments ] $ { arg1 } = par défaut 1 $ { arg2 } = $ { VARIABLE }
[ Documentation ] Ce mot clé prend 0-2 arguments
Log 1er argument $ { arg1 } Log 2ème argument $ { arg2 }

Un requis et un avec défaut

[ Arguments ] $ { requis } $ { facultatif } = par défaut
[ Documentation ] Ce mot clé prend 1-2 arguments
Journal requis: $ { required } Log Facultatif: $ { optionnel }

Valeur par défaut basée sur un argument antérieur

[ Arguments ] $ { a } $ { b } = $ { a } $ { c } = $ { a } et $ { b }
devraient être égaux $ { a } $ { b } devrait être égal à $ { c } $
{ a } et $ { b }

Lorsqu'un mot clé accepte plusieurs arguments avec des valeurs par défaut et que
seuls certains d'entre eux doivent être remplacés, il est souvent utile d'utiliser
la syntaxe des arguments nommés . Lorsque cette syntaxe est utilisée avec des mots-
clés utilisateur, les arguments sont spécifiés sans la ${} décoration. Par exemple, le
deuxième mot-clé ci-dessus pourrait être utilisé comme ci-dessous
et ${arg1}obtiendrait toujours sa valeur par défaut.
*** Cas de test ***
Exemple
Deux arguments avec valeurs par défaut arg2 = nouvelle valeur

Comme tous les Pythonistas doivent l'avoir déjà remarqué, la syntaxe de

spécification des arguments par défaut est fortement inspirée de la syntaxe Python
pour les valeurs par défaut des fonctions.

Varargs avec des mots-clés utilisateur

Parfois, même les valeurs par défaut ne suffisent pas et il faut un mot clé
acceptant un nombre variable d'arguments . Les mots-clés utilisateur prennent
également en charge cette fonctionnalité. Tout ce qui est nécessaire est d'avoir
une variable de liste comme @{varargs}après les arguments de position possibles
dans la signature du mot clé. Cette syntaxe peut être combinée avec les valeurs par
défaut décrites précédemment et, à la fin, la variable de liste obtient tous les
arguments restants qui ne correspondent pas aux autres arguments. La variable de
liste peut donc avoir un nombre quelconque d'éléments, même zéro.
*** Mots clés ***
N'importe quel nombre d'arguments
[ Arguments ] @ { varargs }
Log Many @ { varargs }

Un ou plusieurs arguments
[ Arguments ] $ { required } @ { rest }
Log Many $ { required } @ { rest }

Obligatoire, par défaut, Varargs

[ Arguments ] $ { req } $ { opt } = 42 @ { others }
Journal requis: $ { req } Journal Facultatif: $ { opt } Log Autres:

: FOR $ { item } IN @ { others }

\ Log $ { item }

Notez que si le dernier mot-clé ci-dessus est utilisé avec plusieurs arguments, le
second argument ${opt}obtient toujours la valeur donnée au lieu de la valeur par
défaut. Cela se produit même si la valeur donnée est vide. Le dernier exemple
illustre également comment un nombre variable d'arguments acceptés par un mot-
clé utilisateur peut être utilisé dans une boucle for . Cette combinaison de deux
fonctions plutôt avancées peut parfois être très utile.

Les mots-clés dans les exemples ci-dessus pourraient être utilisés, par exemple,
comme ceci:
*** Cas de test ***
Varargs avec des mots-clés utilisateur
 N'importe quel nombre d'arguments
Tout nombre d'arguments arg
N'importe quel nombre d'arguments arg1 arg2 arg3 arg4
Un ou plusieurs arguments requis
Un ou plusieurs arguments arg1 arg2 arg3 arg4
Obligatoire, par défaut, Varargs requis
Obligatoire, par défaut, Varargs requis facultatif
Obligatoire, valeur par défaut, Varargs arg1 arg2 arg3 arg4 arg5

Encore une fois, Pythonistas remarquera probablement que la syntaxe du nombre

variable d'arguments est très proche de celle de Python.

Kwargs avec des mots-clés d'utilisateur

Les mots-clés utilisateur peuvent également accepter des arguments de mots-clés
gratuits en ayant une variable de dictionnaire comme &{kwargs}le dernier argument
après les arguments de position possibles et les varargs. Lorsque le mot-clé est
appelé, cette variable obtient tous les arguments nommés qui ne correspondent à
aucun argument de position dans la signature du mot-clé.
*** Mots clés ***
Kwargs seulement
[ Arguments ] & { kwargs }
Log $ { kwargs } Log Many @ { kwargs }

Positionnel et kwargs
[ Arguments ] $ { required } & { extra }
Log Many $ { required } @ { extra }

Exécuter de programme
[ Arguments ] @ { varargs } & { kwargs }
Exécuter le processus program.py @ { varargs } & { kwargs }

Le dernier exemple ci-dessus montre comment créer un mot-clé wrapper qui

accepte tout argument positionnel ou nommé et les transmet. Voir les exemples de
kwargs pour un exemple complet avec le même mot-clé.

De même, la prise en charge de kwargs par les mots-clés utilisateur fonctionne de

manière très similaire à celle de kwargs en Python. Dans la signature et aussi lors
du passage des arguments, &{kwargs}est à peu près la même que celle de
Python **kwargs.

2.6.5 Incorporation d’arguments au nom du mot clé

Robot Framework permet également de transmettre des arguments aux mots-clés
utilisateur plutôt que de les spécifier dans les cellules après le nom du mot-clé,
comme expliqué dans la section précédente. Cette méthode repose sur l’intégration
directe des arguments dans le nom du mot-clé. Son principal avantage est de
faciliter l’utilisation de phrases réelles et claires en tant que mots-clés.
Syntaxe de base
Il a toujours été possible d'utiliser des mots-clés tels que Sélectionner un chien dans
la liste et Sélectionne un chat dans la liste , mais tous ces mots-clés doivent avoir
été implémentés séparément. L'idée d'incorporer des arguments dans le nom du mot
clé est que tout ce dont vous avez besoin est un mot clé avec le nom Select $
{animal} de la liste .
*** Mots clés ***
Sélectionnez $ { animal } dans la liste
Ouvrir une page pour animaux de compagnie
Sélectionner un élément dans la liste animal_list $ { animal }

Les mots-clés utilisant des arguments incorporés ne peuvent pas prendre

d'arguments "normaux" (spécifiés avec le paramètre [Arguments] ), mais sinon ils
sont créés comme les autres mots-clés utilisateur. Les arguments utilisés dans le
nom seront naturellement disponibles dans le mot clé et leur valeur dépend de la
manière dont le mot clé est appelé. Par exemple, ${animal}dans le précédent, a une
valeur dogsi le mot-clé est utilisé comme Sélectionner un chien dans la
liste . Évidemment, il n'est pas obligatoire d'utiliser tous ces arguments dans le mot
clé et ils peuvent donc être utilisés comme caractères génériques.

Ces types de mots-clés sont également utilisés de la même manière que les autres
mots-clés, sauf que les espaces et les traits de soulignement ne sont pas ignorés
dans leurs noms. Ils sont cependant insensibles à la casse comme les autres mots-
clés. Par exemple, le mot-clé dans l'exemple ci-dessus pourrait être utilisé
comme select x from list , mais pas comme Select x fromlist .

Les arguments incorporés ne prennent pas en charge les valeurs par défaut ou le
nombre variable d'arguments, contrairement aux arguments normaux. L'utilisation
de variables lors de l'appel de ces mots clés est possible, mais cela peut réduire la
lisibilité. Notez également que les arguments incorporés ne fonctionnent qu'avec
des mots-clés utilisateur.

Les arguments incorporés correspondant trop

Une partie délicate de l’utilisation d’arguments incorporés consiste à s’assurer que
les valeurs utilisées lors de l’appel du mot-clé correspondent aux arguments
corrects. Ceci est un problème surtout si plusieurs arguments et caractères les
séparant peuvent également apparaître dans les valeurs données. Par exemple, le
mot-clé Select $ {city} $ {team} ne fonctionne pas correctement s'il est utilisé avec
une ville contenant également des parties telles que Select Los Angeles Lakers .

Une solution simple à ce problème consiste à citer les arguments (par

exemple, sélectionnez "$ {city}" "$ {team}" ) et utilisez le mot-clé au format cité
(par exemple, sélectionnez "Los Angeles" "Lakers" ). Cette approche ne suffit
cependant pas à résoudre tous ces types de conflits, mais elle est toujours fortement
recommandée car elle fait ressortir les arguments du reste du mot-clé. Une solution
plus puissante mais aussi plus complexe, utilisant des expressions régulières
personnalisées lors de la définition de variables, est expliquée dans la section
suivante. Enfin, si les choses se compliquent, il pourrait être préférable d’utiliser
plutôt des arguments de position normaux.

Le problème des arguments correspondant trop se produit souvent lors de la

création de mots-clés qui ignorent les préfixes donnés / when / then / et / mais . Par
exemple, $ {name} va à la maison , étant donné que Janne rentre à la maison, ce
qui donne de la ${name}valeur Given Janne. Citations autour de l'argument, comme
dans "$ {name}" rentre à la maison , résoudre ce problème facilement.

Utilisation d'expressions régulières personnalisées

Lorsque des mots-clés avec des arguments incorporés sont appelés, les valeurs sont
mises en correspondance en interne à l'aide d' expressions régulières (regexps en
abrégé). La logique par défaut est telle que chaque argument du nom est remplacé
par un modèle .*?qui correspond à n'importe quelle chaîne. Cette logique
fonctionne assez bien normalement, mais comme nous venons de le voir ci-dessus,
les mots-clés correspondent parfois plus que prévu . Citer ou séparer les arguments de
l'autre texte peut aider, mais, par exemple, le test ci-dessous échoue car le mot
clé que j'exécute "ls" avec "-lh" correspond aux deux mots clés définis.
*** Cas de test ***
Exemple
J'exécute "ls"
J'exécute "ls" avec "-lh"

*** Mots clés ***

J'exécute " $ { cmd } "
Exécuter le processus $ { cmd } shell = True

J'exécute " $ { cmd } " avec " $ { opts } "

Exécuter le processus $ { cmd } $ { opts } shell = True

Une solution à ce problème consiste à utiliser une expression régulière

personnalisée qui vérifie que le mot-clé correspond uniquement à ce qu'il doit
contenir dans ce contexte particulier. Pour pouvoir utiliser cette fonctionnalité et
comprendre pleinement les exemples de cette section, vous devez au moins
comprendre les bases de la syntaxe des expressions régulières.

Une expression régulière d'argument incorporé personnalisé est définie après le

nom de base de l'argument afin que l'argument et l'expression rationnelle soient
séparés par un deux-points. Par exemple, un argument qui doit correspondre
uniquement aux nombres peut être défini comme ${arg:\d+}. L'utilisation des
expressions régulières personnalisées est illustrée par les exemples ci-dessous.
*** Cas de test ***
Exemple
J'exécute "ls"
J'exécute "ls" avec "-lh"
Je tape 1 + 2
Je tape 53 - 11
Aujourd'hui est le 2011-06-27

*** Mots clés ***

J'exécute " $ { cmd: [^"] + } "
Exécuter le processus $ { cmd } shell = True

J'exécute " $ { cmd } " avec " $ { opts } "

Exécuter le processus $ { cmd } $ { opts } shell = True

Je tape $ { a: \ d + } $ { operator: [+ -] } $ { b: \ d + } Calculer $

{ a } $ { operator } $ { b }

Aujourd'hui, c'est $ { date: \ d {4 \} - \ d {2 \} - \ d {2 \} }

Log $ { date }

Dans le mot - clé exemple ci - dessus , j'execute "ls" avec "-lh" correspond
seulement j'execute "$ {cmd}" avec "$ {} opts" . Cela est garanti parce que
l'expression régulière personnalisée [^"]+dans j'exécuter « $ {cmd: [^ »]} » signifie
qu'un argument correspondant ne peut pas contenir de guillemets Dans ce cas , il
n'y a pas besoin d'ajouter regexps personnalisés à l'autre. J'exécute la variante.

Pointe

Si vous citez des arguments, l'utilisation d'une expression régulière [^"]+ garantit que
l'argument ne correspond qu'à la première citation finale.

Syntaxe des expressions régulières prises en charge

Implémenté avec Python, Robot Framework utilise naturellement le module re de

Python qui a une syntaxe d'expressions régulières assez standard . Cette syntaxe est par
ailleurs entièrement prise en charge avec les arguments incorporés, mais les
extensions de regexp en format (?...)ne peuvent pas être utilisées. Notez
également que les arguments incorporés correspondants sont insensibles à la
casse. Si la syntaxe des expressions régulières n'est pas valide, la création du mot-
clé échoue avec une erreur visible dans les erreurs d'exécution de test .

Échapper des caractères spéciaux

Certains caractères spéciaux doivent être échappés lorsqu'ils sont utilisés dans les
arguments intégrés personnalisés regexp. Tout d'abord, les accolades éventuelles de
fermeture ( }) dans le motif doivent être échappées avec une seule barre oblique
inverse ( \}), sinon l'argument se terminerait déjà par là. Ceci est illustré dans
l'exemple précédent avec le mot clé Today est $ {date: \ d {4 \} - \ d {2 \} - \ d {2
\}} .
La barre oblique inverse ( \ ) est un caractère spécial dans la syntaxe des
expressions régulières Python et doit donc être échappée si vous souhaitez avoir un
caractère de barre oblique inverse littérale. La séquence d'échappement la plus sûre
dans ce cas est quatre barres obliques inverses ( \\\\) mais, selon le caractère
suivant, deux barres obliques inverses peuvent suffire.

Notez également que les noms de mots-clés et les éventuels arguments incorporés
ne doivent pas être échappés en utilisant les règles d'échappement standard des
données de test . Cela signifie que, par exemple, les barres obliques inverses dans des
expressions telles ${name:\w+}que ne doivent pas être échappées.

Utilisation de variables avec des expressions régulières d'argument incorporé

personnalisé

Chaque fois que des expressions régulières d'argument incorporé personnalisé sont
utilisées, Robot Framework améliore automatiquement les expressions rationnelles
spécifiées afin qu'elles correspondent aux variables en plus du texte correspondant
au modèle. Cela signifie qu'il est toujours possible d'utiliser des variables avec des
mots-clés contenant des arguments incorporés. Par exemple, le scénario de test
suivant passerait en utilisant les mots-clés de l'exemple précédent.
*** Variables ***
$ { DATE } 2011-06-27

*** Cas de test ***

Exemple
Je tape $ { 1 } + $ { 2 }
aujourd'hui est $ { DATE }

Un inconvénient des variables correspondant automatiquement aux expressions

régulières personnalisées est qu'il est possible que la valeur obtenue par le mot clé
ne corresponde pas réellement à l'expression rationnelle spécifiée. Par exemple, la
variable ${DATE}dans l'exemple ci-dessus pourrait contenir n'importe quelle valeur
et Today est $ {DATE} correspondrait toujours au même mot clé.

Exemple de développement axé sur le comportement

Le plus grand avantage d'avoir des arguments dans le nom du mot-clé est qu'il
facilite l'utilisation de mots-clés de type phrase plus complexes lors de l'écriture de
scénarios de test dans un style axésur les comportements . L'exemple ci-dessous
illustre cela. Notez également que les préfixes Given , When et Then sont exclus des
définitions de mots-clés .

*** Cas de test ***

Ajouter deux nombres
Étant donné que j'ai la calculatrice ouverte
Quand j'ajoute 2 et 40
Alors le résultat devrait être 42
Ajouter des nombres négatifs
Étant donné que j'ai la calculatrice ouverte
Quand j'ajoute 1 et -2
Alors le résultat devrait être -1

*** Mots clés ***

J'ai $ { programme } ouvert
Démarrer le programme $ { programme }

J'ajoute $ { number 1 } et $ { number 2 }

Numéro d'entrée $ { number 1 } Bouton poussoir +

Numéro d'entrée $ { number 2 }

Bouton poussoir =

Le résultat doit être $ { expected }

$ { result } = Obtenir le résultat
Devrait être égal à $ { result } $ { expected }

Remarque

La fonctionnalité d'arguments incorporés dans Framework Robot est inspirée de la manière

dont les définitions d'étape sont créées dans un outil BDD populaire, Concombre .

2.6.6 Valeurs de retour du mot-clé utilisateur

De même que les mots-clés de bibliothèque, les mots-clés utilisateur peuvent
également renvoyer des valeurs. Les valeurs de retour sont généralement définies
avec le paramètre [Return] , mais il est également possible d'utiliser les mots-
clés BuiltIn Return from Keyword et Return From If If . Quelle que soit la manière
dont les valeurs sont renvoyées, elles peuvent être affectées à des variablesdans
des scénarios de test et dans d'autres mots-clés utilisateur.

Utiliser le réglage [Retour]

Le cas le plus courant est qu'un mot-clé utilisateur renvoie une valeur et qu'il est
affecté à une variable scalaire. Lorsque vous utilisez le paramètre [Return] , cela se
fait en ayant la valeur de retour dans la cellule suivante après le paramètre.

Les mots-clés utilisateur peuvent également renvoyer plusieurs valeurs, qui peuvent
ensuite être affectées à plusieurs variables scalaires à la fois, à une variable de liste
ou à des variables scalaires et à une variable de liste. Plusieurs valeurs peuvent être
renvoyées simplement en spécifiant ces valeurs dans des cellules différentes après
le paramètre [Return] .
*** Cas de test ***
Une valeur de retour
$ { ret } = Renvoie l' argument One Value
Quelques mots-clés $ { ret }

Valeurs multiples
$ { a } $ { b } $ { c } = Retourne trois valeurs
 @ { list } = Renvoyer trois valeurs
$ { scalar } @ { rest } = Retourne trois valeurs

*** Mots clés ***

Renvoyer une valeur
[ Arguments ] $ { arg }
Quelque chose $ { arg } $ { value } = Obtenir une valeur

[ Retour ] $ { valeur }

Renvoyer trois valeurs

[ Retour ] foo bar zap

Utiliser des mots-clés spéciaux pour retourner

Mots- clés intégrés Retour du mot - clé et retour du mot-clé Si autoriser le retour
conditionnel d'un mot-clé utilisateur au milieu du mot-clé. Les deux acceptent
également les valeurs de retour facultatives qui sont traitées exactement comme
avec le paramètre [Retour] décrit ci-dessus.

Le premier exemple ci-dessous est fonctionnellement identique à l'exemple

précédent [Return] . Le deuxième exemple, plus avancé, illustre le retour
conditionnel dans une boucle for .
*** Cas de test ***
Une valeur de retour
$ { ret } = Renvoie l' argument One Value
Quelques mots-clés $ { ret }

Avancée
@ { list } = Créer la liste foo baz
$ { index } = Trouver l'index baz @ { list } Devrait être égal
à $ { index } $ { 1 } $ { index } = Rechercher l'index non
existant @ { list } Devrait être égal à $ { index } $ { -1 }

*** Mots clés ***

Renvoyer une valeur
[ Arguments ] $ { arg }
Quelque chose $ { arg } $ { value } = Obtenir une valeur

Retour du mot-clé $ { value }

Fail Ceci n'est pas exécuté

Trouver l'index
[ Arguments ] $ { element } @ { items }
$ { index } = Définissez la variable $ { 0 }
: FOR $ { item } IN @ { items }
\ Retour du mot-clé si ' $ { item } ' == ' $ { element } ' $ {
index } \ $ { index } = Définir la variable $ { index + 1 }
Renvoyer le mot clé $ { -1 }

# Peut aussi utiliser [Retour]

Remarque
Les deux valeurs renvoyées par le mot - clé et Retour de mot-clé sont disponibles depuis
Robot Framework 2.8.

2.6.7 Décryptage du mot-clé utilisateur

Les mots-clés utilisateur peuvent avoir une suppression définie à l'aide
du paramètre [Teardown] .

Le démontage des mots clés fonctionne de la même manière que le démontage

d' un scénario de test . Plus important encore, le démontage est toujours un mot-clé
unique, bien qu'il puisse s'agir d'un autre mot-clé utilisateur, et il s'exécute
également lorsque le mot-clé utilisateur échoue. De plus, toutes les étapes de la
suppression sont exécutées même si l'une d'elles échoue. Cependant, un échec de la
suppression du mot clé échouera dans le cas de test et les étapes suivantes du test
ne seront pas exécutées. Le nom du mot-clé à exécuter en tant que suppression peut
également être une variable.
*** Mots clés ***
Avec le déchirement
Faire quelque chose
[ Teardown ] Démolition du mot clé du journal

Utiliser des variables

[ Documentation ] Démolition donnée en variable
Faire quelque chose
[ Teardown ] $ { TEARDOWN }

2.7 Fichiers de ressources et variables

Les mots-clés utilisateur et les variables dans les fichiers de scénarios de test et les
fichiers d'initialisation de la suite de tests ne peuvent être utilisés que dans les fichiers où
ils sont créés, mais les fichiers de ressources permettent de les partager. Comme la
structure du fichier de ressources est très proche des fichiers de cas de test, il est
facile de les créer.

Les fichiers de variables fournissent un mécanisme puissant pour créer et partager

des variables. Par exemple, ils autorisent des valeurs autres que des chaînes et
permettent la création dynamique de variables. Leur flexibilité vient du fait qu'ils
sont créés à l'aide du code Python, ce qui les rend également un peu plus
compliqués que les tables Variable .

 2.7.1 Fichiers de ressources

o Utilisation de fichiers de ressources
o Structure du fichier de ressources
o Documentation des fichiers de ressources
o Exemple de fichier de ressource
 2.7.2 Fichiers variables
o Utiliser des fichiers variables
 o Création de variables directement
o Obtenir des variables à partir d'une fonction spéciale
o Implémenter un fichier de variables en tant que classe Python ou Java
o Fichier variable comme YAML

2.7.1 Fichiers de ressources

Utilisation de fichiers de ressources
Les fichiers de ressources sont importés à l'aide du paramètre Ressource du tableau
Paramètres. Le chemin d'accès au fichier de ressources est indiqué dans la cellule
après le nom du paramètre.

Si le chemin est donné dans un format absolu, il est utilisé directement. Dans
d'autres cas, le fichier de ressources est d'abord recherché par rapport au répertoire
dans lequel se trouve le fichier d'importation. Si le fichier n'y est pas trouvé, il est
ensuite recherché dans les répertoires du chemin de recherche du module Python . Le
chemin peut contenir des variables et il est recommandé de les utiliser pour rendre
les chemins indépendants du système (par exemple, $ {RESOURCES}
/login_resources.html ou $ {RESOURCE_PATH} ). En outre, les barres obliques
( /) dans le chemin d'accès sont automatiquement remplacées par des barres
obliques inverses ( \ ) sous Windows.
*** Paramètres ***
Ressource myresources.html
Ressource ../data/resources.html
Ressource $ { RESSOURCES } /common.tsv

Les mots-clés utilisateur et les variables définis dans un fichier de ressources sont
disponibles dans le fichier qui utilise ce fichier de ressources. De même, tous les
mots-clés et variables des bibliothèques, fichiers de ressources et fichiers de
variables importés par ledit fichier de ressources sont également disponibles.

Structure du fichier de ressources

La structure de niveau supérieur des fichiers de ressources est identique à celle des
fichiers de scénarios de test, mais, bien sûr, ils ne peuvent pas contenir de tables de
cas de test. En outre, le tableau Paramètres des fichiers de ressources ne peut
contenir que les paramètres d'importation ( bibliothèque , ressource , variables ) et
la documentation . La table des variables et le tableau des mots-clés sont utilisés
exactement de la même manière que dans les fichiers de scénarios de test.

Si plusieurs fichiers de ressources ont un mot-clé utilisateur portant le même nom,

ils doivent être utilisés pour que le nom du mot - clé soit préfixé par le nom du fichier de
ressource sans extension (par exemple, myresources.Some
Keyword et common.Some ). De plus, si plusieurs fichiers de ressources
contiennent la même variable, celle qui est importée en premier est utilisée.

Documentation des fichiers de ressources

Les mots-clés créés dans un fichier de ressources peuvent être documentés à l' aide
du paramètre [Documentation] . Le fichier de ressources lui-même peut contenir
la Documentation dans le tableau Paramètres de la même manière que les suites de
tests .

Les deux Libdoc et RIDE utilisent ces documentations, et ils sont naturellement
disponibles pour les fichiers de ressources d' ouverture de la personne. La première
ligne de la documentation d'un mot clé est consignée lors de son exécution, sinon
les documentations de fichier de ressources sont ignorées lors de l'exécution du test.

Exemple de fichier de ressource

*** Paramètres ***
Documentation Un exemple de fichier de ressources
Bibliothèque SeleniumLibrary
Ressource $ { RESSOURCES } /common.robot

*** Variables ***

$ { HOST } localhost: 7272
$ { URL de connexion } http: // $ { HOST } /
$ { URL de BIENVENUE } http: // $ { HOST } /welcome.html
$ { NAVIGATEUR } Firefox

*** Mots clés ***

Ouvrir la page de connexion
[ Documentation ] Ouvre le navigateur pour vous connecter à la page
Ouvrir le navigateur $ { URL de connexion } $ { NAVIGATEUR } Le
titre devrait être la page de connexion

Nom d'entrée
[ Arguments ] $ { name }
Texte d'entrée username_field $ { name }

Saisir mot de passe

[ Arguments ] $ { password }
Texte de saisie password_field $ { password }

2.7.2 Fichiers variables

Les fichiers variables contiennent des variables pouvant être utilisées dans les
données de test. Les variables peuvent également être créées à l'aide de tables de
variables ou définies à partir de la ligne de commande, mais les fichiers de
variables permettent de les créer dynamiquement et leurs variables peuvent contenir
des objets.
Les fichiers de variables sont généralement implémentés en tant que modules
Python et il existe deux approches différentes pour la création de variables:

Création de variables directement

Les variables sont spécifiées comme attributs de module. Dans des cas
simples, la syntaxe est si simple qu'aucune programmation réelle n'est
nécessaire. Par exemple, MY_VAR = 'my value'crée une
variable ${MY_VAR}avec le texte spécifié comme valeur.
Obtenir des variables à partir d'une fonction spéciale
Les fichiers de variables peuvent avoir
une méthode spéciale get_variables (ou getVariables) qui renvoie des
variables en tant que mappage. Comme la méthode peut prendre des
arguments, cette approche est très flexible.

Alternativement, des fichiers variables peuvent être implémentés en tant que classes
Python ou Java que le framework instanciera. Dans ce cas également, il est possible
de créer des variables en tant qu’attributs ou de les extraire d’une méthode spéciale.

Utiliser des fichiers variables

Table de réglage

Tous les fichiers de données de test peuvent importer des variables à l'aide
du paramètre Variables de la table Setting, de la même manière que les fichiers de
ressources sont importés à l'aide du paramètre Resource . De même que pour les
fichiers de ressources, le chemin d'accès au fichier de variables importé est
considéré par rapport au répertoire dans lequel se trouve le fichier d'importation et,
s'il n'est pas trouvé, il est recherché dans les répertoires du chemin de
recherche du module . Le chemin peut également contenir des variables et les barres
obliques sont converties en barres obliques inverses sous Windows. Si un fichier
d'argument prend des arguments , ils sont spécifiés dans les cellules après le chemin et
peuvent également contenir des variables.
*** Paramètres ***
Variables myvariables.py
Variables ../data/variables.py
Variables $ { RESOURCES } /common.py
Variables Taking_arguments.py arg1 $ { ARG2 }

Toutes les variables d'un fichier de variables sont disponibles dans le fichier de
données de test qui les importe. Si plusieurs fichiers de variables sont importés et
qu'ils contiennent une variable portant le même nom, celle du fichier importé le
plus ancien est utilisée. De plus, les variables créées dans les tables de variables et
définies à partir de la ligne de commande remplacent les variables des fichiers de
variables.
Ligne de commande

Une autre façon d'utiliser des fichiers variables consiste à utiliser l'option de ligne
de commande --variablefile . Les fichiers de variables sont référencés en
utilisant un chemin vers eux et les arguments possibles sont joints au chemin avec
un signe deux-points ( :):
--variablefile myvariables.py
--variablefile path / variables.py
--variablefile /absolute/path/common.py
--variablefile taking_arguments.py:arg1:arg2

À partir de Robot Framework 2.8.2, les fichiers de variables utilisés depuis la ligne
de commande sont également recherchés à partir du chemin de recherche du module,
de la même manière que les fichiers de variables importés dans le tableau Setting.

Si un fichier de variables est fourni sous la forme d'un chemin d'accès Windows
absolu, les deux points après la lettre du lecteur ne sont pas considérés comme un
séparateur:
--variablefile C: \ path \ variables.py

À partir de Robot Framework 2.8.7, il est également possible d'utiliser un point-

virgule ( ;) comme séparateur d'arguments. Ceci est utile si les arguments de fichier
variable eux-mêmes contiennent des deux-points, mais nécessitent d’englober toute
la valeur avec des guillemets sur les systèmes d’exploitation de type UNIX:
--variablefile "myvariables.py; argument: avec: colons"
--variablefile C: \ path \ variables.py; D: \ data.xls

Les variables de ces fichiers de variables sont globalement disponibles dans tous
les fichiers de données de test, de même que les variables individuelles définies avec
l' option --variable . Si les deux options --variablefile et --
variable sont utilisées et qu'il existe des variables avec les mêmes noms, celles
qui sont définies individuellement avec l' option --variable sont prioritaires.

Création de variables directement

Syntaxe de base

Lorsque des fichiers de variables sont utilisés, ils sont importés en tant que modules
Python et tous leurs attributs globaux qui ne commencent pas par un trait de
soulignement ( _) sont considérés comme des variables. Comme les noms de
variable ne sont pas sensibles à la casse, les noms de majuscules et de minuscules
sont possibles, mais en général, les majuscules sont recommandées pour les
variables et les attributs globaux.
VARIABLE = "Un exemple de chaîne"
ANOTHER_VARIABLE = "C'est assez simple!"
INTEGER = 42
STRINGS = [ "un" , "deux" , "kolme" , "quatre" ]
NUMBERS = [ 1 , ENTIER , 3.14 ]
MAPPING = { "un" : 1 , "deux" : 2 , "trois" : 3 }

Dans l'exemple ci-dessus, des variables ${VARIABLE}, ${ANOTHER VARIABLE}etc., sont

créées. Les deux premières variables sont des chaînes, la troisième est un entier, il y
a deux listes et la valeur finale est un dictionnaire. Toutes ces variables peuvent être
utilisées comme une variable scalaire , des listes et le dictionnaire aussi une variable
de liste comme @{STRINGS}(dans le cas du dictionnaire cette variable ne contiendrait
que des clés), et le dictionnaire aussi comme une variable de
dictionnaire comme &{MAPPING}.

Pour rendre la création d'une variable de liste ou d'une variable de dictionnaire plus
explicite, il est possible de préfixer le nom de la variable avec LIST__ou DICT__,
respectivement:
à partir de collections import OrderedDict

LIST__ANIMALS = [ "cat" , "dog" ]

DICT__FINNISH = OrderedDict ([( "chat" , "kissa" ), ( "chien" ,
"koira" )])

Ces préfixes ne feront pas partie du nom de la variable finale, mais ils permettront à
Robot Framework de valider que la valeur est réellement similaire à une liste ou à
un dictionnaire. Avec les dictionnaires, la valeur stockée réelle est également
transformée en un dictionnaire spécial utilisé également lors de la création de
variables de dictionnaire dans la table Variable. Les valeurs de ces dictionnaires sont
accessibles en tant qu'attributs comme ${FINNISH.cat}. Ces dictionnaires sont
également classés, mais la conservation de l’ordre source nécessite également la
commande du dictionnaire d’origine.

Les variables dans les deux exemples ci-dessus pourraient être créées en utilisant
également le tableau Variable ci-dessous.
*** Variables ***
$ { VARIABLE } Un exemple de chaîne
$ { UNE AUTRE VARIABLE } C'est assez facile!
$ { INTEGER } $ { 42 }
@ { STRINGS } un deux kolme quatre
@ { NUMBERS } $ { 1 } $ { INTEGER } $ { 3.14 }
& { MAPPING } one = $ { 1 } deux = $ { 2 } trois =
$ { 3 }
@ { ANIMALS } chat chien
& { FINNISH } cat = kissa dog = koira

Remarque
Les variables ne sont pas remplacées dans les chaînes issues de fichiers variables. Par
exemple, VAR = "an ${example}"créerait une variable ${VAR}avec une valeur de chaîne
littérale, an ${example}indépendamment du fait que la variable ${example} existe ou non.

Utiliser des objets comme valeurs

Les variables dans les fichiers de variables ne sont pas limitées à avoir uniquement
des chaînes ou d'autres types de base en tant que valeurs telles que les tables de
variables. Au lieu de cela, leurs variables peuvent contenir des objets. Dans
l'exemple ci-dessous, la variable ${MAPPING}contient une table de hachage Java avec
deux valeurs (cet exemple ne fonctionne que lors de l'exécution de tests sur
Jython).
à partir de java.util import Hashtable

MAPPING = Hashtable ()
MAPPING . mettre ( "un" , 1 )
MAPPING . mettre ( "deux" , 2 )

Le deuxième exemple crée ${MAPPING}un dictionnaire Python et comporte

également deux variables créées à partir d'un objet personnalisé implémenté dans le
même fichier.
MAPPING = { 'one' : 1 , 'two' : 2 }

class MyObject :
def __init__ ( self , name ):
self . nom = nom

OBJ1 = MyObject ( 'John' )

OBJ2 = MyObject ( 'Jane' )

Création dynamique de variables

Comme les fichiers de variables sont créés à l'aide d'un langage de programmation
réel, ils peuvent être dotés d'une logique dynamique pour définir les variables.
importation os
importation aléatoire
import temps

USER = os . getlogin () # nom de connexion actuel

RANDOM_INT = random . randint ( 0 , 10 ) # entier aléatoire dans
l'intervalle [0,10]
CURRENT_TIME = heure . asctime () # timestamp like 'jeu 6 avril
12:45:21 2006'
si heure . localtime () [ 3 ] > 12 :
APRÈS - MIDI = Vrai
sinon :
APRÈS - MIDI = Faux

L'exemple ci-dessus utilise des bibliothèques Python standard pour définir

différentes variables, mais vous pouvez utiliser votre propre code pour construire
les valeurs. L'exemple ci-dessous illustre le concept, mais de même, votre code
peut lire les données d'une base de données, d'un fichier externe ou même le
demander à l'utilisateur.
importer des maths

def get_area ( diamètre ):

rayon = diamètre / 2
surface = math . pi * rayon * rayon
retour zone

AREA1 = get_area ( 1 )
AREA2 = get_area ( 2 )

Sélection des variables à inclure

Lorsque Robot Framework traite des fichiers de variables, tous les attributs qui ne
commencent pas par un trait de soulignement doivent être des variables. Cela
signifie que même les fonctions ou les classes créées dans le fichier de variables ou
importées d’ailleurs sont considérées comme des variables. Par exemple, le dernier
exemple contiendrait les variables ${math} et ${get_area}en plus
de ${AREA1}et ${AREA2}.

Normalement, les variables supplémentaires ne posent pas de problèmes, mais elles

peuvent remplacer d'autres variables et provoquer des erreurs de débogage
difficiles. Une possibilité d'ignorer d'autres attributs est de les préfixer avec un trait
de soulignement:
importer des maths comme _math

def _get_area ( diamètre ):

rayon = diamètre / 2.0
zone = _math . pi * rayon * rayon
retour zone

AREA1 = _get_area ( 1 )
AREA2 = _get_area ( 2 )

S'il existe un grand nombre d'autres attributs, au lieu de les préfixer, il est souvent
plus facile d'utiliser un attribut spécial __all__et de lui donner une liste de noms
d'attributs à traiter en tant que variables.
importer des maths

__all__ = [ 'AREA1' , 'AREA2' ]

def get_area ( diamètre ):

rayon = diamètre / 2.0
zone = math . pi * rayon * rayon
retour zone

AREA1 = get_area ( 1 )
AREA2 = get_area ( 2 )
Remarque

L' __all__attribut est également et à l'origine utilisé par Python pour déterminer les attributs
à importer lors de l'utilisation de la syntaxe from modulename import *.

Obtenir des variables à partir d'une fonction spéciale

Une autre approche pour obtenir des variables est d'avoir
une get_variablesfonction spéciale (la syntaxe camelCase getVariablesest
également possible) dans un fichier variable. Si une telle fonction existe, Robot
Framework l'appelle et s'attend à recevoir des variables en tant que dictionnaire
Python ou Java Mapavec des noms de variable en tant que clés et des valeurs de
variable en tant que valeurs. Les variables créées peuvent être utilisées comme
scalaires, listes et dictionnaires exactement comme lors de la création directe de
variables , et il est possible d'utiliser LIST__et de DICT__préfixes pour rendre plus
explicite la création de variables de liste et de dictionnaire. L'exemple ci-dessous
est fonctionnellement identique au premier exemple de création de variables .
def get_variables ():
variables = { "VARIABLE" : "Un exemple de chaîne" ,
"UNE AUTRE VARIABLE" : "C'est assez simple!" ,
"ENTIER" : 42 ,
"STRINGS" : [ "one" , "two" , "kolme" , "four" ],
"NUMBERS" : [ 1 , 42 , 3.14 ],
"MAPPING" : { "one" : 1 , "trois" : 3 }}
variables de retour

get_variablespeut également prendre des arguments, ce qui facilite la modification

des variables réellement créées. Les arguments de la fonction sont définis comme
tous les autres arguments pour une fonction Python. Lors de l' utilisation de fichiers
variables dans les données de test, les arguments sont spécifiés dans les cellules
après le chemin d'accès au fichier de variable et, dans la ligne de commande, ils
sont séparés par un signe deux-points ou un point-virgule.

L'exemple factice ci-dessous montre comment utiliser des arguments avec des
fichiers de variables. Dans un exemple plus réaliste, l'argument peut être un chemin
d'accès à un fichier texte externe ou à une base de données à partir duquel lire les
variables.
variables1 = { 'scalar' : 'Variable scalaire' ,
'LIST__list' : [ 'List' , 'variable' ]}
variables2 = { 'scalar' : 'Une autre valeur' ,
'LIST__list' : [ 'Some' , 'other ' , ' value ' ],
' extra ' : ' variables1 n'a pas du tout ' }

def get_variables ( arg ):

if arg == 'one' :
retourne les variables1
sinon :
retourne les variables2
Implémenter un fichier de variables en tant que classe Python ou
Java
À partir de Robot Framework 2.7, il est possible d'implémenter des fichiers de
variables en tant que classes Python ou Java.

la mise en oeuvre

Les fichiers de variables étant toujours importés via un chemin de système de

fichiers, leur création en tant que classes est soumise à certaines restrictions:

 Les classes Python doivent avoir le même nom que le module dans
lequel elles se trouvent.
 Les classes Java doivent vivre dans le package par défaut.
 Les chemins d' accès aux classes Java doivent se terminer
par .java ou .class . Le fichier de classe doit exister dans les deux cas.

Indépendamment du langage d'implémentation, le framework créera une instance

de la classe sans arguments et les variables seront extraites de l'instance. De même
que pour les modules, les variables peuvent être définies comme des attributs
directement dans l'instance ou obtenus à partir
d'une méthode spéciale get_variables (ou getVariables).

Lorsque des variables sont définies directement dans une instance, tous les attributs
contenant des valeurs appelables sont ignorés pour éviter de créer des variables à
partir des méthodes possibles de l'instance. Si vous avez réellement besoin de
variables appelables, vous devez utiliser d'autres approches pour créer des fichiers
variables.

Exemples

Les premiers exemples créent des variables à partir d'attributs utilisant Python et
Java. Les deux créent des variables ${VARIABLE}et @{LIST}des attributs de classe
et ${ANOTHER VARIABLE}d'un attribut d'instance.
class StaticPythonExample ( object ):
variable = 'value'
LIST__list = [ 1 , 2 , 3 ]
_not_variable = 'commence par un trait de soulignement'

def __init__ ( self ):

self . another_variable = 'une autre valeur'
classe publique StaticJavaExample {
public static String variable = "value" ;
public static String [] LIST__list = { 1 , 2 , 3 };
private String notVariable = "is private" ;
public String anotherVariable ;
 public StaticJavaExample () {
anotherVariable = "une autre valeur" ;
}
}

Le deuxième exemple utilise une approche dynamique pour obtenir des

variables. Les deux créent une seule variable ${DYNAMIC VARIABLE}.
classe DynamicPythonExample ( objet ):

def get_variables ( self , * args ):

return { 'variable dynamique' : '' . rejoindre ( args )}
import java.util.Map ;
import java.util.HashMap ;

classe publique DynamicJavaExample {

public Map < String , String > getVariables ( String arg1 , String
arg2 ) {
HashMap < String , String > variables = new HashMap < String ,
String > ();
variables . put ( "variable dynamique" , arg1 + "" + arg2 );
les variables de retour ;
}
}

Fichier variable comme YAML

Les fichiers variables peuvent également être implémentés en tant
que fichiers YAML . YAML est un langage de sérialisation de données avec une
syntaxe simple et conviviale. L'exemple suivant illustre un fichier YAML simple:
string : Bonjour, monde!
nombre entier : 42
liste :
- un
- deux
dict :
un : yksi
deux : kaksi
avec des espaces : kolme

Remarque

L'utilisation de fichiers YAML avec Robot Framework nécessite l' installation

du module PyYAML . Si vous avez installé pip , vous pouvez l'installer simplement en
exécutant pip install pyyaml.

Le support YAML est nouveau dans Robot Framework 2.9. À partir de la version 2.9.2,
la distribution JAR autonome contient PyYAML par défaut.

Les fichiers de variables YAML peuvent être utilisés exactement comme les
fichiers de variables normaux à partir de la ligne de commande en utilisant
l' option --variablefile , dans le tableau de paramètres utilisant le
paramètre Variables , et dynamiquement à l'aide du mot clé Import Variables . La
seule chose à retenir est que les chemins d'accès aux fichiers YAML doivent
toujours se terminer par l' extension .yaml .

Si le fichier YAML ci-dessus est importé, il créera exactement les mêmes variables
que la table de variables suivante:
*** Variables ***
$ { STRING } Bonjour tout le monde!
$ { INTEGER } $ { 42 }
@ { LIST } un deux
& { DICT } one = yksi two = kaksi

Les fichiers YAML utilisés comme fichiers de variables doivent toujours être des
mappages au niveau supérieur. Comme le montre l'exemple ci-dessus, les clés et les
valeurs du mappage deviennent respectivement des noms de variables et des
valeurs. Les valeurs de variable peuvent être tout type de données pris en charge
par la syntaxe YAML. Si les noms ou les valeurs contiennent des caractères non-
ASCII, les fichiers de variables YAML doivent être codés en UTF-8.

Les mappages utilisés comme valeurs sont automatiquement convertis en

dictionnaires spéciaux utilisés lors de la création de variables de dictionnaire dans la
table de variables. Plus important encore, les valeurs de ces dictionnaires sont
accessibles en tant qu’attributs ${DICT.one}, par exemple en supposant que leurs
noms sont valides en tant que noms d’attributs Python. Si le nom contient des
espaces ou n'est pas un nom d'attribut valide, il est toujours possible d'accéder aux
valeurs du dictionnaire en utilisant une syntaxe telle que la &{DICT}[with
spaces]syntaxe. Les dictionnaires créés sont également classés, mais
malheureusement, l'ordre source d'origine dans le fichier YAML n'est pas conservé.

2.8 Fonctions avancées

 2.8.1 Manipulation des mots clés portant le même nom
o Étendues de mots clés
o Spécification d'un mot clé explicitement
o Spécification de la priorité explicite entre les bibliothèques et les ressources
 2.8.2 Temporisation
o Test du délai d'expiration
o Délai de mot clé utilisateur
 2.8.3 Pour les boucles
o Normal pour la boucle
o Imbriqué pour les boucles
o Utiliser plusieurs variables de boucle
o Boucle dans la gamme
o Boucle pour énumération
o Boucle pour zip
o Sortie pour boucle
 o Continuer pour la boucle
o Suppression des mots-clés inutiles des sorties
o Répétition d'un mot clé unique
 2.8.4 Exécution conditionnelle
 2.8.5 Exécution parallèle de mots-clés

2.8.1 Manipulation des mots clés portant le même nom

Les mots-clés utilisés avec Robot Framework sont des mots - clés de
bibliothèque ou des mots-clés d'utilisateur . Les premiers proviennent de bibliothèques
standard ou de bibliothèques externes , et les seconds sont soit créés dans le même
fichier où ils sont utilisés, soit importés à partir de fichiers de ressources . Lorsque de
nombreux mots-clés sont utilisés, il est fréquent que certains d'entre eux portent le
même nom, et cette section décrit comment gérer les conflits possibles dans ces
situations.

Étendues de mots clés

Lorsque seul un nom de mot-clé est utilisé et que plusieurs mots-clés portent ce
nom, Robot Framework tente de déterminer quel mot-clé a la priorité la plus élevée
en fonction de son étendue. La portée du mot clé est déterminée en fonction de la
manière dont le mot clé en question est créé:

1. Créé en tant que mot-clé utilisateur dans le même fichier où il est utilisé. Ces
mots-clés ont la plus haute priorité et sont toujours utilisés, même s’il existe
d’autres mots-clés portant le même nom.
2. Créé dans un fichier de ressources et importé directement ou indirectement à
partir d'un autre fichier de ressources. C'est la deuxième priorité.
3. Créé dans une bibliothèque de test externe. Ces mots-clés sont utilisés s'il n'y
a pas de mots-clés d'utilisateur portant le même nom. Toutefois, s'il existe un
mot-clé portant le même nom dans la bibliothèque standard, un
avertissement s'affiche.
4. Créé dans une bibliothèque standard. Ces mots clés ont la plus faible
priorité.

Spécification d'un mot clé explicitement

Les étendues seules ne sont pas une solution suffisante, car il peut exister des mots-
clés portant le même nom dans plusieurs bibliothèques ou ressources et, par
conséquent, ils fournissent un mécanisme permettant d’utiliser uniquement le mot-
clé de la plus haute priorité. Dans ce cas, il est possible d'utiliser le nom complet du
mot-clé , où le nom du mot-clé est précédé du nom de la ressource ou de la
bibliothèque et où un point est un délimiteur.
Avec les mots-clés de bibliothèque, le format long signifie que vous utilisez
uniquement le format LibraryName.Keyword Name . Par exemple, le mot
clé Exécuter à partir de la bibliothèque OperatingSystem peut être utilisé en tant
que OperatingSystem.Run , même s'il existe un autre mot clé Run ailleurs. Si la
bibliothèque se trouve dans un module ou un package, le nom complet du module
ou du package doit être utilisé (par exemple, com.company.Library.Some
Keyword ). Si un nom personnalisé est attribué à une bibliothèque à l'aide de
la syntaxe WITH NAME , le nom spécifié doit également être utilisé dans le nom
complet du mot clé.

Les fichiers de ressources sont spécifiés dans le nom complet du mot clé, tout
comme les noms de bibliothèque. Le nom de la ressource est dérivé du nom de base
du fichier de ressources sans l'extension de fichier. Par exemple, le mot-
clé Exemple dans un fichier de ressources myresources.html peut être utilisé
comme mes ressources.Exemple . Notez que cette syntaxe ne fonctionne pas si
plusieurs fichiers de ressources ont le même nom de base. Dans ce cas, les fichiers
ou les mots-clés doivent être renommés. Le nom complet du mot-clé est insensible
à la casse, à l'espace et au trait de soulignement, de même que les noms de mots-
clés normaux.

Spécification de la priorité explicite entre les bibliothèques et les

ressources
S'il y a plusieurs conflits entre les mots-clés, spécifier tous les mots-clés dans le
format long peut être très compliqué. L'utilisation du format long rend également
impossible la création de scénarios de test dynamiques ou de mots clés utilisateur
fonctionnant différemment selon les bibliothèques ou les ressources
disponibles. Une solution à ces deux problèmes consiste à spécifier explicitement
les priorités des mots-clés à l'aide du mot-clé Définir l'ordre de recherche de
la bibliothèque dans la bibliothèque BuiltIn .

Remarque

Bien que le mot-clé ait la bibliothèque de mots dans son nom, il fonctionne également avec
les fichiers de ressources. Comme mentionné ci-dessus, les mots-clés dans les ressources ont
toujours une priorité plus élevée que les mots-clés dans les bibliothèques.

L' ordre de recherche Set Library accepte une liste ordonnée ou des bibliothèques
et des ressources en tant qu'arguments. Lorsqu'un nom de mot clé dans les données
de test correspond à plusieurs mots clés, la première bibliothèque ou ressource
contenant le mot clé est sélectionnée et cette implémentation de mot clé est
utilisée. Si le mot clé n'est trouvé dans aucune des bibliothèques ou ressources
spécifiées, l'exécution échoue en cas de conflit de la même manière que lorsque
l'ordre de recherche n'est pas défini.
Pour plus d'informations et d'exemples, consultez la documentation du mot clé.

2.8.2 Temporisation
Les mots-clés peuvent être problématiques dans des situations où ils sont
extrêmement longs à exécuter ou simplement suspendus sans fin. Robot
Framework vous permet de définir des délais d'attente à la fois pour les scénarios
de test et les mots - clés utilisateur . Si un test ou un mot-clé n'est pas terminé dans le
délai imparti, le mot-clé en cours d'exécution est stoppé. Arrêter les mots-clés de
cette manière peut laisser la bibliothèque ou le système testé dans un état instable,
et les délais d'attente ne sont recommandés que si aucune option plus sûre n'est
disponible. En général, les bibliothèques doivent être implémentées de sorte que les
mots-clés ne puissent pas se bloquer ou qu'ils disposent de leur propre mécanisme
de temporisation, si nécessaire.

Test du délai d'expiration

Le délai d'expiration du scénario de test peut être défini à l'aide du paramètre Délai
d'expiration du test dans le tableau Paramètres ou
du paramètre [Temporisation] dans le tableau Test Case. Délai d' attente de
test dans le tableau de réglage définit une valeur de délai d' attente de test par
défaut pour tous les cas de test dans la suite de tests, alors que [Délai
d' attente] dans le tableau cas de test applique un délai d' attente d'un cas de test
individuel et remplace la valeur par défaut possible.

L'utilisation d'un [Timeout] vide signifie que le test n'a pas de délai d'attente, même
lorsque le Délai de test est utilisé. Il est également possible d'utiliser de la
valeur NONEà cette fin.

Indépendamment de l'endroit où le délai d'expiration du test est défini, la première

cellule après le nom du paramètre contient la durée du délai d'attente. La durée doit
être indiquée dans le format d'heure de Robot Framework , c'est-à-dire directement en
secondes ou dans un format similaire 1 minute 30 seconds. Il convient de noter que
le cadre comporte toujours des frais généraux et que les délais d'attente inférieurs à
une seconde ne sont donc pas recommandés.

Le message d'erreur par défaut affiché lorsqu'un délai d'attente de test se produit
est Test timeout <time> exceeded. Il est également possible d'utiliser des messages
d'erreur personnalisés et ces messages sont écrits dans les cellules après le délai
d'expiration. Le message peut être divisé en plusieurs cellules, de même que les
documentations. La valeur du délai d'attente et le message d'erreur peuvent contenir
des variables.

En cas de dépassement de délai, le mot clé en cours d'exécution est arrêté à

l'expiration du délai d'attente et le scénario de test échoue. Cependant, les mots-clés
exécutés en tant que suppression de test ne sont pas interrompus en cas de
dépassement du délai de test, car ils sont normalement impliqués dans des activités
de nettoyage importantes. Si nécessaire, il est possible d'interrompre également ces
mots-clés avec les délais d'expiration des mots- clés de l' utilisateur .
*** Paramètres ***
Délai de test 2 minutes

*** Cas de test ***

Délai d'expiration par défaut
[ Documentation ] Timeout du tableau Setting est utilisé
Certains arguments mot-clé

Passer outre
[ Documentation ] Remplacer par défaut, utiliser 10 secondes
[ Timeout ] 10
Certains arguments mot-clé

Message personnalisé
[ Documentation ] Remplacez par défaut et utilisez un message
personnalisé
[ Timeout ] 1min 10s Ceci est mon erreur personnalisée
Certains arguments mot-clé

Les variables
[ Documentation ] Il est possible d'utiliser des variables aussi
[ Timeout ] $ { TIMEOUT }
Un argument de mot clé

Pas de timeout
[ Documentation ] Le délai d'expiration vide signifie qu'il n'y a
pas de délai d'attente, même si le délai d'expiration du test a été
utilisé.
[ Timeout ]
Un argument mot clé

Pas de délai d'attente 2

[ Documentation ] La désactivation du délai d'attente avec NONE
fonctionne également et est plus explicite.
[ Timeout ] AUCUN
Certains arguments mot-clé

Délai de mot clé utilisateur

Un délai peut être défini pour un mot-clé utilisateur à l'aide
du paramètre [Timeout] dans le tableau des mots-clés. La syntaxe permettant de la
définir, notamment la manière dont les valeurs de délai d'attente et les éventuels
messages personnalisés sont fournis, est identique à celle utilisée avec les délais
d' expiration des scénarios de test . Si aucun message personnalisé n'est fourni, le
message d'erreur par défaut Keyword timeout <time> exceededest utilisé en cas de
dépassement de délai.

À partir de Robot Framework 3.0, le délai d'attente peut être spécifié en tant que
variable afin que la valeur de la variable soit donnée en tant
qu'argument. L'utilisation de variables globales fonctionne déjà avec les versions
précédentes.
*** Mots clés ***
Mot-clé chronométré
[ Documentation ] Définissez uniquement la valeur du délai
d'attente et non le message personnalisé.
[ Temporisation ] 1 minute 42 secondes
Faire quelque chose
Faire autre chose

Wrapper avec timeout

[ Arguments ] @ { args }
[ Documentation ] Ce mot clé est un wrapper qui ajoute un délai
d'attente à un autre mot clé.
[ Timeout ] 2 minutes Le mot-clé d'origine n'a pas été terminé en 2
minutes
Mot-clé d'origine @ { args }

Emballage avec délai d'attente personnalisable

[ Arguments ] $ { timeout } @ { args }
[ Documentation ] Idem que ci-dessus mais délai donné en argument.
[ Timeout ] $ { timeout }
Mot-clé d'origine @ { args }

Un délai de mot-clé utilisateur est applicable lors de l'exécution de ce mot-clé

utilisateur. Si la durée totale du mot-clé est supérieure à la valeur du délai, le mot-
clé actuellement exécuté est arrêté. Les délais d'expiration des mots clés utilisateur
sont également applicables lors du démontage d'un scénario de test, contrairement
aux délais d'attente de test.

Si le scénario de test et certains de ses mots-clés (ou plusieurs mots-clés imbriqués)

ont un délai d'attente, le délai d'attente actif est celui avec le moins de temps.

2.8.3 Pour les boucles

Répéter plusieurs fois les mêmes actions est un besoin courant dans
l’automatisation des tests. Avec Robot Framework, les bibliothèques de test
peuvent avoir tout type de construction de boucle, et la plupart des boucles de
temps doivent y être implémentées. Robot Framework possède également sa propre
syntaxe de boucle, utile par exemple lorsqu'il est nécessaire de répéter les mots-clés
de différentes bibliothèques.

Les boucles for peuvent être utilisées avec les scénarios de test et les mots-clés
utilisateur. Sauf pour les cas vraiment simples, les mots-clés utilisateur sont
meilleurs, car ils masquent la complexité introduite par les boucles for. La syntaxe
de base pour les boucles FOR item IN sequenceest dérivée de Python, mais une
syntaxe similaire est également possible dans les scripts shell ou Perl.

Normal pour la boucle

Dans une boucle normale, une variable est assignée à partir d'une liste de valeurs,
une valeur par itération. La syntaxe commence par :FOR, où deux points sont requis
pour séparer la syntaxe des mots clés normaux. La cellule suivante contient la
variable de boucle, la cellule suivante doit avoir INet les cellules finales contiennent
des valeurs sur lesquelles effectuer une itération. Ces valeurs peuvent contenir
des variables , y compris des variables de liste .

Les mots-clés utilisés dans la boucle for se trouvent sur les lignes suivantes et
doivent être indentés une cellule à droite. Lorsque vous utilisez le format texte brut ,
les cellules en retrait doivent être échappées avec une barre oblique inverse , mais avec
d'autres formats de données, les cellules peuvent être laissées vides. La boucle for
se termine lorsque l'indentation revient à la normale ou que la table se termine.
*** Cas de test ***
Exemple 1
: POUR $ { animal } EN chien chat
\ Log $ { animal }
\ Log 2nd mot clé
Journal en dehors de la boucle

Exemple 2
: FOR $ { var } IN one two
... $ { 3 } quatre $ { last }
\ Log $ { var }

La boucle for de l' exemple 1 ci-dessus est exécutée deux fois, de sorte que la
variable de boucle ${animal}a d'abord la valeur catet ensuite dog. La boucle est
composée de deux mots-clés Log . Dans le deuxième exemple, les valeurs de
boucle sont divisées en deux lignes et la boucle est exécutée cinq fois.

Il est souvent pratique d'utiliser des boucles avec des variables de liste . Ceci est
illustré par l'exemple ci-dessous, où @{ELEMENTS}contient une liste d'éléments
arbitrairement longue et le mot-clé Elément de départ est utilisé avec chacun d'eux
un par un.
*** Cas de test ***
Exemple
: POUR $ { element } IN @ { ELEMENTS }
\ Start Element $ { element }

Imbriqué pour les boucles

Avoir imbriqué des boucles n'est pas directement pris en charge, mais il est
possible d'utiliser un mot-clé utilisateur dans une boucle for et d'en utiliser un autre
pour la boucle.
*** Mots clés ***
Table de poignée
[ Arguments ] @ { table }
: FOR $ { row } IN @ { table }
\ Handle Row @ { row }
Rangée de poignée
[ Arguments ] @ { row }
: FOR $ { cell } IN @ { row }
\ Handle Cell $ { cellule }

Utiliser plusieurs variables de boucle

Il est également possible d'utiliser plusieurs variables de boucle. La syntaxe est la
même que pour la boucle normale, mais toutes les variables de boucle sont
répertoriées dans les cellules situées entre :FORet IN. Il peut y avoir un nombre
quelconque de variables de boucle, mais le nombre de valeurs doit pouvoir être
divisé par le nombre de variables.

S'il y a beaucoup de valeurs à itérer, il est souvent pratique de les organiser sous les
variables de boucle, comme dans la première boucle de l'exemple ci-dessous:
*** Cas de test ***
Trois variables de boucle
: POUR $ { index } $ { english } $ { finnois } IN
... 1 chat kissa
... 2 koira de chien
... 3 chevaux hevonen
\ Ajouter au dictionnaire $ { english } $ { finnois } $ { index
}
: FOR $ { name } $ { id } IN @ { EMPLOYERS }
\ Créer $ { name } $ { id }

Boucle dans la gamme

Plus tôt pour les boucles toujours itérées sur une séquence, et c'est aussi le cas
d'utilisation le plus courant. Parfois, il est toujours pratique d’avoir une boucle for
exécutée un certain nombre de fois, et Robot Framework a unFOR index IN RANGE
limit syntaxe à cet effet. Cette syntaxe est dérivée de l'idiome Python similaire.

De même que pour les autres boucles, la boucle for-in-range commence par :FORet
la variable loop se trouve dans la cellule suivante. Dans ce format, il ne peut y avoir
qu’une seule variable de boucle et il contient l’indice de boucle en cours. La cellule
suivante doit contenir IN RANGEet les cellules suivantes limites de boucle.

Dans le cas le plus simple, seule la limite supérieure de la boucle est

spécifiée. Dans ce cas, les index de boucle commencent à zéro et augmentent de un
jusqu'à la limite, mais à l'exclusion de celle-ci. Il est également possible de donner
les limites de début et de fin. Les index commencent alors par la limite de début,
mais augmentent de la même manière que dans le cas simple. Enfin, il est possible
de donner également la valeur de pas qui spécifie l’incrément à utiliser. Si le pas est
négatif, il est utilisé comme décrément.
Il est possible d'utiliser des arithmétiques simples telles que l'addition et la
soustraction avec les limites de l'intervalle. Ceci est particulièrement utile lorsque
les limites sont spécifiées avec des variables.

À partir de Robot Framework 2.8.7, il est possible d'utiliser des valeurs flottantes
pour la limite inférieure, la limite supérieure et l'étape.
*** Cas de test ***
Seule la limite supérieure
[ Documentation ] Boucles sur les valeurs de 0 à 9
: POUR $ { index } DANS LA GAMME 10
\ Log $ { index }

Début et fin
[ Documentation ] Boucles sur des valeurs de 1 à 10
: POUR $ { index } DANS LA GAMME 1 11
\ Log $ { index }

Aussi étape donnée

[ Documentation ] Boucles sur les valeurs 5, 15 et 25
: POUR $ { index } DANS LA GAMME 5 26 10
\ Log $ { index }

Pas négatif
[ Documentation ] Boucles sur les valeurs 13, 3 et -7
: POUR $ { index } DANS LA GAMME 13 -13 -10
\ Log $ { index }

Arithmétique
[ Documentation ] Arithmétique avec variable
: FOR $ { index } IN RANGE $ { var } +1
\ Log $ { index }

Paramètres de flottement
[ Documentation ] Boucles sur les valeurs 3.14, 4.34 et 5.54
: POUR $ { index } DANS LA GAMME 3.14 6.09 1.2
\ Log $ { index }

Boucle pour énumération

Parfois, il est utile de parcourir une liste et de suivre votre position dans la
liste. Robot Framework a une FOR index ... IN ENUMERATE
...syntaxe spéciale pour cette situation. Cette syntaxe est dérivée de la fonction
intégrée Python .

Les boucles pour-en-énumérer fonctionnent exactement comme les boucles pour

les boucles, sauf la cellule après les variables de boucle IN ENUMERATE, et doivent
avoir une variable d'index supplémentaire avant toute autre variable de
boucle. Cette variable d'index a la valeur 0pour la première itération, 1pour la
seconde, etc.

Par exemple, les deux cas de test suivants font la même chose:
*** Variables ***
@ { LISTE } a b c

*** Cas de test ***

Gérer l'index manuellement
$ { index } = Définir la variable -1
: FOR $ { item } IN @ { LIST }
\ $ { index } = Évaluer $ { index } + 1
\ Mon mot clé $ { index } $ { item }

Pour en énumérer
: FOR $ { index } $ { item } IN ENUMERATE @ { LIST }
\ Mon mot clé $ { index } $ { item }

Tout comme pour les boucles régulières, vous pouvez effectuer une boucle sur
plusieurs valeurs par itération de boucle tant que le nombre de valeurs de votre liste
est divisible par le nombre de variables de boucle (à l'exclusion de la première
variable d'index).
*** Cas de test ***
Pour-en-énumérer avec deux valeurs par itération
: POUR $ { index } $ { english } $ { finlandais } IN ENUMERATE
... cat kissa
... chien koira
... cheval hevonen
\ Ajouter au dictionnaire $ { english } $ { finlandais } $ {
index }

Les boucles pour énumération sont nouvelles dans Robot Framework 2.9.

Boucle pour zip

Certains tests construisent plusieurs listes associées, puis les parcourent
ensemble. Robot Framework comporte un raccourci pour ce cas: FOR ... IN ZIP
...dérivé de la fonction zip intégrée de Python .

Cela peut être plus facile à montrer avec un exemple:

*** Variables ***
@ { NUMBERS } $ { 1 } $ { 2 } $ { 5 }
@ { NAMES } un deux cinq

*** Cas de test ***

Itérer deux listes manuellement
$ { length } = Obtenir la longueur $ { NUMBERS }
: POUR $ { idx } DANS LA GAMME $ { length }
\ Number doit être nommé $ { NUMBERS } [ $ { idx } ] $ {
NAMES } [ $ { idx } ]

For-in-zip
: POUR $ { number } $ { name } IN ZIP $ { NUMBERS } $ { NAMES }
\ Number doit être nommé $ { number } $ { name }

De même que pour les boucles for-in-range et for-in-enumerate, les boucles for-in-
zip nécessitent que la cellule après les variables de boucle soit lue IN ZIP.
Les valeurs utilisées avec les boucles for-in-zip doivent être des listes ou des objets
de type liste, et le nombre de variables de boucle et de listes doit être le même. Le
bouclage s'arrêtera lorsque la liste la plus courte sera épuisée.

Notez que toutes les listes utilisées avec pour en-zip devrait généralement être
donné comme variables scalaires aiment ${list}. Une variable de liste ne fonctionne
que si ses éléments sont eux-mêmes des listes.

Les boucles for-in-zip sont nouvelles dans Robot Framework 2.9.

Sortie pour boucle

Normalement, les boucles sont exécutées jusqu'à ce que toutes les valeurs de boucle
aient été itérées ou qu'un mot-clé utilisé dans la boucle échoue. S'il est nécessaire
de quitter la boucle plus tôt, lesmots-clés intégrés Exit For Loop et Exit For Loop
If peuvent être utilisés pour y parvenir. Ils fonctionnent de la même manière
quebreak instructions en Python, Java et dans de nombreux autres langages de
programmation.

Exit For Loop et Exit For Loop Si les mots-clés peuvent être utilisés directement
dans une boucle for ou dans un mot-clé utilisé par la boucle. Dans les deux cas,
l'exécution du test se poursuit après la boucle. C'est une erreur d'utiliser ces mots-
clés en dehors d'une boucle for.
*** Cas de test ***
Exemple de sortie
$ { text } = Définir la variable $ { EMPTY }
: FOR $ { var } IN one two
\ Run Keyword Si ' $ { var } ' == 'deux' Quittez For Loop
\ $ { text } = Définir la variable $ { text } $ { var }
doit être égale à $ { text } one

Dans l'exemple ci-dessus, il serait possible d'utiliser Exit For Loop If au lieu
d'utiliser Exit For Loop avec Run Keyword If . Pour plus d'informations sur ces
mots clés, y compris d'autres exemples d'utilisation, consultez leur documentation
dans la bibliothèque BuiltIn .

Remarque

Exit For Loop Si un mot clé a été ajouté dans Robot Framework 2.8.

Continuer pour la boucle

En plus de sortir prématurément une boucle for, il est également possible de
continuer à l'itération suivante de la boucle avant que tous les mots-clés aient été
exécutés. Cela peut être fait en utilisant les mots-clés BuiltIn Continue For
Loop et Continue For Loop If , qui fonctionnent comme des continueinstructions
dans de nombreux langages de programmation.

Continuer pour la boucle et continuer pour la boucle Si les mots-clés peuvent être
utilisés directement dans une boucle for ou dans un mot-clé utilisé par la
boucle. Dans les deux cas, le reste des mots-clés dans cette itération est ignoré et
l'exécution continue à partir de l'itération suivante. Si ces mots-clés sont utilisés
lors de la dernière itération, l'exécution se poursuit après la boucle. C'est une erreur
d'utiliser ces mots-clés en dehors d'une boucle for.
*** Cas de test ***
Continuer Exemple
$ { text } = Définir la variable $ { EMPTY }
: FOR $ { var } IN un deux trois
\ Continue For Loop Si ' $ { var } ' == 'two'
\ $ { text } = Définir la variable $ { text } $ { var }
Devrait être égale $ { text } onethree

Pour plus d'informations sur ces mots clés, y compris des exemples d'utilisation,
consultez leur documentation dans la bibliothèque BuiltIn .

Remarque

Les deux Continuer boucle For et Continuer boucle For Si ont été ajoutés dans le cadre Robot
2.8.

Suppression des mots-clés inutiles des sorties

Pour les boucles avec plusieurs itérations, elles génèrent souvent beaucoup de
résultats et augmentent considérablement la taille des fichiers
de sortie et des fichiers journaux générés . À partir de Robot Framework 2.7, il est
possible de supprimer les mots-clés inutiles des sorties à l'aide de l' option de ligne de
commande --RemoveKeywords FOR .

Répétition d'un mot clé unique

Car les boucles peuvent être excessives dans les situations où il suffit de répéter un
seul mot-clé. Dans ces cas, il est souvent plus facile d'utiliser le mot-clé
de répétition BuiltIn . Ce mot-clé prend un mot-clé et combien de fois le répéter en
argument. Les temps de répétition du mot-clé peuvent avoir un postfix
optionnel ou rendre la syntaxe plus facile à lire.timesx
*** Cas de test ***
Exemple
Répéter le mot-clé 5 Certains mots-clés arg1 arg2
Répéter Mot-clé 42 fois Mon mot-clé
Répéter le mot-clé $ { var } Un autre argument de mot-clé
2.8.4 Exécution conditionnelle
En général, il n'est pas recommandé d'avoir une logique conditionnelle dans les
scénarios de test, ni même dans les mots-clés des utilisateurs, car cela peut les
rendre difficiles à comprendre et à gérer. Au lieu de cela, ce type de logique devrait
être dans des bibliothèques de test, où il peut être implémenté en utilisant des
constructions de langage de programmation naturel. Cependant, une logique
conditionnelle peut parfois être utile, et même si Robot Framework n’a pas de
construction if / else, il existe plusieurs manières d’obtenir le même effet.

 Le nom du mot-clé utilisé en tant que configuration ou en cas de suppression

des scénarios de test et des suites de tests peut être spécifié à l'aide d'une
variable. Cela facilite leur modification, par exemple depuis la ligne de
commande.
 Le mot-clé BuiltIn Run Keyword utilise un mot-clé pour s'exécuter en tant
qu'argument et peut donc être une variable. La valeur de la variable peut, par
exemple, être obtenue dynamiquement à partir d'un mot clé antérieur ou
fournie à partir de la ligne de commande.
 Les mots-clés BuiltIn Run Keyword If et Run Keyword Sauf si un mot-clé
nommé est exécuté uniquement si une certaine expression est vraie ou
fausse, respectivement. Ils conviennent parfaitement à la création de
constructions if / else simples. Pour un exemple, voir la documentation de
l'ancien.
 Un autre mot-clé BuiltIn , Set Variable If , peut être utilisé pour définir des
variables basées dynamiquement sur une expression donnée.
 Plusieurs mots-clés BuiltIn permettent d'exécuter un mot-clé nommé
uniquement si un scénario de test ou une suite de tests a échoué ou réussi.

2.8.5 Exécution parallèle de mots-clés

Lorsqu'une exécution parallèle est nécessaire, elle doit être implémentée au niveau
de la bibliothèque de tests afin que la bibliothèque exécute le code en arrière-
plan. Généralement, cela signifie que la bibliothèque a besoin d'un mot clé tel
que Démarrer quelque chose qui lance l'exécution et renvoie immédiatement, et un
autre mot clé comme Obtenir les résultats de quelque chose qui attend que le
résultat soit disponible et le renvoie. Voir Mots-clés de la
bibliothèque OperatingSystem Processus de démarrage et sortie du processus de
lecture pour un exemple.

3 Exécution des cas de test

 3.1 Utilisation de base
 3.2 Exécution du test
  3.3 Résultats du post-traitement
 3.4 Configuration de l'exécution
 3.5 sorties créées

3.1 Utilisation de base

Les scénarios de test de la structure de robot sont exécutés à partir de la ligne de
commande et le résultat final est, par défaut, un fichier de sortie au format XML et
un rapport et un journal HTML . Après l'exécution, les fichiers de sortie peuvent être
combinés et traités ultérieurement à l'aide de l'outil Rebot.

 3.1.1 Lancement de l'exécution du test

o Synopsis
o Spécification des données de test à exécuter
 3.1.2 Utilisation des options de ligne de commande
o Utiliser les options
o Options courtes et longues
o Définition des valeurs d'option
o Désactiver les options en acceptant aucune valeur
o Motifs simples
o Motifs d'étiquette
o Variables d' environnement ROBOT_OPTIONS et REBOT_OPTIONS
 3.1.3 Résultats du test
o Sortie ligne de commande
o Fichiers de sortie générés
o Codes retour
o Erreurs et avertissements pendant l'exécution
 3.1.4 Échapper à des personnages compliqués
 3.1.5 Fichiers d'arguments
o Syntaxe du fichier d'argument
o Utiliser des fichiers d'argument
o Lecture de fichiers d'arguments à partir d'une entrée standard
 3.1.6 Obtenir de l'aide et des informations de version
 3.1.7 Création de scripts de démarrage
o Modification des paramètres de démarrage de Java
 3.1.8 Problèmes de débogage
o Utilisation du débogueur Python (pdb)

3.1.1 Lancement de l'exécution du test

Synopsis
robot [options] data_sources
python | jython | ipy -m robot [options] data_sources
python | jython | chemin ipy / to / robot / [options] data_sources
java -jar robotframework.jar [options] data_sources
L'exécution du test est normalement lancée à l'aide du script du robot
d' exécution . Il est également possible d'exécuter le module de robot ou le répertoire
de robot installé directement à l'aide de l'interpréteur sélectionné. La dernière
solution consiste à utiliser la distribution JAR autonome .

Remarque

Les versions antérieures à Robot Framework 3.0 n'avaient pas le script du robot . Au lieu de
cela, ils avaient pybot , jybot et ipybot qui exécutaient les tests avec Python, Jython et
IronPython, respectivement. Ces scripts sont toujours installés, mais il est prévu de les
déprécier et de les supprimer ultérieurement.

Quelle que soit l'approche d'exécution, le ou les chemins d'accès aux données de
test à exécuter sont donnés en tant qu'argument après la commande. De plus,
différentes options de ligne de commande peuvent être utilisées pour modifier
l'exécution du test ou générer des sorties de plusieurs manières.

Spécification des données de test à exécuter

Les scénarios de test de la structure de robot sont créés dans des fichiers et
des répertoires et exécutés en donnant le chemin d'accès au fichier ou au répertoire
en question au script d'exécution sélectionné. Le chemin peut être absolu ou, plus
communément, par rapport au répertoire à partir duquel les tests sont exécutés. Le
fichier ou répertoire donné crée la suite de tests de niveau supérieur, qui reçoit son
nom, à moins d'être remplacé par l' option --name , à partir du nom du fichier ou du
répertoire . Différentes possibilités d'exécution sont illustrées dans les exemples ci-
dessous. Notez que dans ces exemples, ainsi que dans d'autres exemples de cette
section, seul le script du robot est utilisé, mais d'autres approches d'exécution
pourraient être utilisées de la même manière.
robot tests.robot
chemin du robot / vers / my_tests /
robot c: \ robot \ tests.robot

Il est également possible de donner des chemins à plusieurs fichiers de scénarios de

test ou répertoires à la fois, séparés par des espaces. Dans ce cas, Robot Framework
crée automatiquement la suite de tests de niveau supérieur et les fichiers et
répertoires spécifiés deviennent ses suites de tests enfants. Le nom de la suite de
tests créée provient des noms de suites enfants en les regroupant avec une
esperluette (&) et des espaces. Par exemple, le nom de la suite de niveau supérieur
dans le premier exemple ci-dessous est Mes tests et vos tests . Ces noms créés
automatiquement sont souvent assez longs et compliqués. Dans la plupart des cas,
il est donc préférable d'utiliser l' option --name pour la remplacer , comme
dans le deuxième exemple ci-dessous:
robot my_tests.robot your_tests.robot
robot --name Exemple chemin / to / tests / pattern _ *. robot
3.1.2 Utilisation des options de ligne de commande
Robot Framework fournit un certain nombre d'options de ligne de commande
pouvant être utilisées pour contrôler l'exécution des scénarios de test et les sorties
générées. Cette section explique la syntaxe des options et les options existantes. La
façon dont ils peuvent être utilisés est discutée ailleurs dans ce chapitre.

Utiliser les options

Lorsque des options sont utilisées, elles doivent toujours être données entre le script
runner et les sources de données. Par exemple:
robot -L debug my_tests.robot
robot --inclus la fumée - variable HOST: 10.0.0.42 chemin / to / tests
/

Options courtes et longues

Les options ont toujours un nom long, tel que --name , et les options les plus
fréquemment utilisées ont également un nom court, tel que -N . De plus, les
options longues peuvent être raccourcies tant qu'elles sont uniques. Par exemple, --
logle DEBUGworks, tandis que works, --lo log.htmlcar l'ancien ne correspond
qu'à --loglevel , mais le dernier correspond à plusieurs options. Les options
courtes et abrégées sont pratiques lors de l'exécution manuelle de scénarios de test,
mais les options longues sont recommandées dans les scripts de démarrage , car elles
sont plus faciles à comprendre.

Le format d'option longue est insensible à la casse, ce qui facilite l'écriture des
noms d'options dans un format facile à lire. Par exemple, --
SuiteStatLevel est équivalent à, mais plus facile à lire que --
suitestatlevel .

Définition des valeurs d'option

La plupart des options nécessitent une valeur, qui est donnée après le nom de
l'option. Les options courtes et longues acceptent la valeur séparée du nom de
l'option par un espace, comme dans --include tag ou -i tag. Avec les options
longues, le séparateur peut également être le signe égal, par exemple --
include=tag, et avec de courtes options, le séparateur peut être omis, comme dans -
itag.

Certaines options peuvent être spécifiées plusieurs fois. Par exemple, --variable
VAR1:value --variable VAR2:anotherdéfinit deux variables. Si les options qui ne
prennent qu'une valeur sont utilisées plusieurs fois, la dernière valeur est effective.
Désactiver les options en acceptant aucune valeur
Les options n'acceptant aucune valeur peuvent être désactivées en utilisant à
nouveau la même option avec le nopréfixe ajouté ou supprimé. La dernière option a
la priorité quel que soit le nombre de fois où les options sont utilisées. Par
exemple, --dryrun --dryrun --nodryrun --nostatusrc --statusrcn'activerait pas
le mode de fonctionnement à sec et renverrait un statut normal rc.

Remarque

La prise en charge de l'ajout ou de la suppression de nopréfixe est une nouvelle fonctionnalité

de Robot Framework 2.9. Dans les versions antérieures, les options n'acceptant aucune valeur
pouvaient être désactivées à l'aide de la même option.

Motifs simples
De nombreuses options de ligne de commande prennent des arguments en tant
que modèles simples . Ces modèles globaux correspondent aux règles suivantes:

 * est un caractère générique correspondant à n'importe quelle chaîne, même

une chaîne vide.
 ? est un caractère générique correspondant à n'importe quel caractère.
 Sauf indication contraire, la correspondance de motif est insensible à la
casse, à l'espace et au trait de soulignement.

Exemples:
--test Exemple * # Correspond aux tests avec le nom commençant par
'Exemple', sans tenir compte de la casse.
--incluez f ?? # Correspond aux tests avec un tag qui commence par 'f'
ou 'F' et comporte trois caractères.

Motifs d'étiquette
La plupart des options associées aux balises acceptent les arguments
comme modèles de balises . Ils ont toutes les mêmes caractéristiques que
les modèles simples , mais ils soutiennent également AND, ORet les NOTopérateurs
expliqués ci - dessous. Ces opérateurs peuvent être utilisés pour combiner plusieurs
balises ou motifs individuels.

AND ou &

L'ensemble du motif correspond si tous les motifs individuels

correspondent. ANDet &sont équivalents:
--include fooANDbar # Correspond aux tests contenant les tags
'foo' et 'bar'.
 --exclude xx & yy & zz # Correspond aux tests contenant les
balises 'xx', 'yy' et 'zz'.
OR

L'ensemble du motif correspond à n'importe quel motif:

--include fooORbar # Correspond aux tests contenant la balise
'foo' ou la balise 'bar'.
--exclude xxORyyORzz # Correspond aux tests contenant l'un des
tags 'xx', 'yy' ou 'zz'.
NOT

Le motif entier correspond si le motif sur le côté gauche correspond mais pas
sur le côté droit. S'il est utilisé plusieurs fois, aucun des motifs après le
premier NOTne doit correspondre:
--include fooNOTbar # Correspond aux tests contenant la balise
'foo' mais pas la balise 'bar'.
--exclude xxNOTyyNOTzz # Correspond aux tests contenant le tag
'xx' mais pas au tag 'yy' ou au tag 'zz'.

À partir de Robot Framework 2.9, le modèle peut également commencer

avec le NOT cas où le motif correspond si le motif suivant NOTne correspond
pas:
--include NOTfoo # Correspond aux tests ne contenant pas le tag
'foo'
--include NOTfooANDbar # Correspond aux tests ne contenant pas
les tags 'foo' et 'bar'

Les opérateurs ci-dessus peuvent également être utilisés ensemble. La priorité de

l' opérateur, du plus élevé au plus bas, est AND, ORet NOT:
--include xANDyORz # Correspond aux tests contenant les balises 'x' et
'y' ou la balise 'z'.
--include xORyNOTz # Correspond aux tests contenant la balise 'x' ou
'y', mais pas la balise 'z'.
--include xNOTyANDz # Correspond aux tests contenant la balise 'x',
mais pas aux tags 'y' et 'z'.

Bien que la correspondance des balises soit insensible à la casse, tous les opérateurs
sont sensibles à la casse et doivent être écrits avec des majuscules. Si les balises
elles-mêmes contiennent des majuscules AND, ORou NOT, elles doivent être spécifiées
en utilisant des lettres minuscules pour éviter une utilisation accidentelle par
l'opérateur:
--include port # Correspond aux tests contenant la balise 'port', sans
tenir compte de la casse
--include PORT # Correspond aux tests contenant la balise 'P' ou 'T',
sans tenir compte de la casse
--exclure handoverORportNOTnotification

Remarque
OR L'opérateur est nouveau dans Robot Framework 2.8.4.

Variables d' environnement ROBOT_OPTIONS et REBOT_OPTIONS

Les variables d'environnement ROBOT_OPTIONS et REBOT_OPTIONS peuvent être
utilisées pour spécifier les options par défaut pour l' exécution des tests et le post-
traitement des résultats , respectivement. Les options et leurs valeurs doivent être
définies comme une liste séparée par des espaces et placées devant toutes les
options explicites de la ligne de commande. Le principal cas d'utilisation de ces
variables d'environnement est la définition de valeurs globales par défaut pour
certaines options afin d'éviter de devoir les répéter chaque fois que des tests sont
exécutés ou que Rebot est utilisé.
export ROBOT_OPTIONS = "--régression critique --tagdoc 'mytag: exemple doc
avec des espaces'"
robot tests.robot
export REBOT_OPTIONS = "--reportbackground vert: jaune: rouge"
rebot --name exemple output.xml

Remarque

La prise en charge des variables d'environnement ROBOT_OPTIONS et REBOT_OPTIONS a été

ajoutée dans Robot Framework 2.8.2.

La possibilité d'avoir des espaces dans des valeurs en les entourant entre guillemets est
nouvelle dans Robot Framework 2.9.2.

3.1.3 Résultats du test

Sortie ligne de commande
La sortie la plus visible de l'exécution du test est la sortie affichée dans la ligne de
commande. Toutes les suites de tests et les cas de test exécutés, ainsi que leurs
statuts, y sont affichés en temps réel. L'exemple ci-dessous montre la sortie de
l'exécution d'une simple suite de tests avec seulement deux cas de test:
==================================================
============================
Exemple de suite de tests
==================================================
============================
Premier test :: Documentation de test possible | PASS |
-------------------------------------------------- -------------------
---------
Deuxième test | FAIL |
Le message d'erreur est affiché ici
==================================================
============================
Exemple de suite de tests | FAIL |
2 tests critiques, 1 réussi, 1 échoué
2 tests au total, 1 réussi, 1 échoué
 ==================================================
============================
Sortie: /path/to/output.xml
Rapport: /path/to/report.html
Journal: /path/to/log.html

À partir de Robot Framework 2.7, il y a également une notification sur la console

chaque fois qu'un mot clé de niveau supérieur dans un scénario de test se
termine. Un point vert est utilisé si un mot-clé passe et un mot-clé rouge s'il
échoue. Ces marqueurs sont écrits à la fin de la ligne et sont écrasés par le statut du
test à la fin du test. L'écriture des marqueurs est désactivée si la sortie de la console
est redirigée vers un fichier.

Fichiers de sortie générés

La sortie de la ligne de commande est très limitée et des fichiers de sortie distincts
sont normalement nécessaires pour analyser les résultats du test. Comme le montre
l'exemple ci-dessus, trois fichiers de sortie sont générés par défaut. Le premier est
au format XML et contient toutes les informations sur l'exécution du test. Le
second est un rapport de niveau supérieur et le troisième est un fichier journal plus
détaillé. Ces fichiers et autres fichiers de sortie possibles sont décrits plus en détail
dans la section Différents fichiers de sortie .

Codes retour
Les scripts runner communiquent l'état d'exécution du test au système les exécutant
à l'aide des codes retour. Lorsque l'exécution démarre avec succès et qu'aucun test
critique échoue, le code retour est zéro. Tous les codes de retour possibles sont
expliqués dans le tableau ci-dessous.

Codes de retour possibles

RC Explication

0 Tous les tests critiques ont réussi.

1-249 Le nombre de tests critiques renvoyés a échoué.

250 250 défaillances critiques ou plus.

251 Informations d'aide ou de version imprimées.

252 Données de test ou options de ligne de commande non valides.

253 L'exécution du test est arrêtée par l'utilisateur.

255 Erreur interne inattendue.

Les codes de retour doivent toujours être facilement disponibles après l'exécution,
ce qui facilite la détermination automatique du statut d'exécution global. Par
exemple, dans le shell bash, le code retour est dans une variable spéciale $?et dans
Windows, il est %ERRORLEVEL% variable. Si vous utilisez un outil externe pour
exécuter des tests, consultez sa documentation pour savoir comment obtenir le code
de retour.

Le code de retour peut être défini sur 0 même s'il existe des défaillances critiques à
l'aide de l' option de ligne de commande --NoStatusRC . Cela peut être utile,
par exemple, dans les serveurs d'intégration continue où le post-traitement des
résultats est nécessaire avant que l'état général de l'exécution du test puisse être
déterminé.

Remarque

Les mêmes codes de retour sont également utilisés avec Rebot .

Erreurs et avertissements pendant l'exécution

Lors de l'exécution du test, il peut y avoir des problèmes inattendus, tels que
l'impossibilité d'importer une bibliothèque ou un fichier de ressources ou un mot
clé obsolète . En fonction de la gravité de ces problèmes, ils sont classés comme
erreurs ou avertissements et enregistrés dans la console (à l’aide du flux d’erreurs
standard), dans la section Test Execution Errors des fichiers journaux et dans
le journal système de Robot Framework . Normalement, ces erreurs et avertissements
sont générés par Robot Framework lui-même, mais les bibliothèques peuvent
également enregistrer des erreurs et des avertissements . L'exemple ci-dessous illustre
à quoi ressemblent les erreurs et les avertissements dans le fichier journal.

20090322 ERREUR Erreur dans le fichier '/home/robot/tests.robot' da

19: 58: table 'Setting' dans l'élément de la ligne 2: le fi
42.528 de ressources 'resource.robot' n'existe pas

20090322 PRÉVENIR Le mot clé "SomeLibrary.Example Keyword" est

19: 58: obsolète. Utilisez le mot-clé `Autre mot-clé` à la
43.931

3.1.4 Échapper à des personnages compliqués

Les espaces étant utilisés pour séparer les options les unes des autres, il est
problématique de les utiliser dans les valeurs des options. Certaines options, telles
que --name , convertissent automatiquement les traits de soulignement en
espaces, mais avec d'autres, les espaces doivent être échappés. De plus, de
nombreux caractères spéciaux sont compliqués à utiliser sur la ligne de
commande. Comme l'échappement de caractères compliqués avec une barre
oblique inverse ou la citation des valeurs ne fonctionne pas toujours correctement,
Robot Framework possède son propre mécanisme d'échappement générique. Une
autre possibilité consiste à utiliser des fichiers d'arguments dans lesquels les options
peuvent être spécifiées au format texte brut. Ces deux mécanismes fonctionnent
lors de l'exécution de tests et lors du post-traitement des sorties. Certains outils de
prise en charge externes ont des capacités identiques ou similaires.

Dans le mécanisme d'échappement de la ligne de commande de Robot Framework,

les caractères problématiques sont échappés avec du texte librement
sélectionné. L'option de ligne de commande à utiliser est --escape (-E) , qui
prend un argument au format what:with, oùwhat est le nom du caractère à échapper
et withest la chaîne avec laquelle il doit s'échapper. Les caractères pouvant être
échappés sont répertoriés dans le tableau ci-dessous:

Escapades disponibles

Personnage Nom à utiliser Personnage Nom à utiliser

Et ampli ( paren1

' apos ) paren2

@ à % pour cent

\ bslash | tuyau

: côlon ? quête

, virgule " coté

{ bouclé1 ; sémic

} bouclé2 / sabrer

$ dollar espace

! exclam [ square1

> gt ] square2

# hacher * étoile

< lt

Les exemples suivants rendent la syntaxe plus claire. Dans le premier exemple, les
métadonnées Xobtiennent la valeur Value with spaceset dans le second exemple, la
variable ${VAR}est affectée à"Hello, world!" :
--escape space: _ --metadata X: Value_with_spaces
-E espace: SP -E quot: QU -E virgule: CO -E exclam: EX -v VAR:
QUHelloCOSPworldEXQU
Notez que tous les arguments de ligne de commande donnés, y compris les chemins
d'accès aux données de test, sont échappés. Les séquences de caractères
d'échappement doivent donc être sélectionnées avec soin.

3.1.5 Fichiers d'arguments

Les fichiers d'argument permettent de placer toutes les options et certains
arguments de la ligne de commande dans un fichier externe où ils seront lus. Cela
évite les problèmes avec les caractères problématiques sur la ligne de
commande. Si beaucoup d'options ou d'arguments sont nécessaires, les fichiers
d'argument empêchent également la commande utilisée sur la ligne de commande
de devenir trop longue.

Les fichiers d'argument sont utilisés avec l' option --argumentfile (-

A) avec d'autres options de ligne de commande possibles.

Remarque

Contrairement aux autres options de ligne de commande longues , le fichier --

argumentfile ne peut pas être utilisé dans un format raccourci tel que --
argumentf . De plus, son utilisation insensible à la casse comme --ArgumentFile est
uniquement prise en charge par Robot Framework 3.0.2 et versions ultérieures .

Syntaxe du fichier d'argument

Les fichiers d'arguments peuvent contenir des options de ligne de commande et des
chemins d'accès aux données de test, une option ou une source de données par
ligne. Les options courtes et longues sont prises en charge, mais ces dernières sont
recommandées car elles sont plus faciles à comprendre. Les fichiers d'argument
peuvent contenir n'importe quels caractères sans s'échapper, mais les espaces au
début et à la fin des lignes sont ignorés. De plus, les lignes vides et les lignes
commençant par un signe dièse (#) sont ignorées:
--doc Ceci est un exemple (où "les caractères spéciaux" sont ok!)
--metadata X: Valeur avec des espaces
--variable VAR: Bonjour, monde!
# Ceci est un commentaire
chemin / vers / mes / tests

Dans l'exemple ci-dessus, le séparateur entre les options et leurs valeurs est un
espace unique. Dans Robot Framework 2.7.6 et versions ultérieures, il est possible
d'utiliser un signe égal (=) ou un nombre quelconque d'espaces. Par exemple, les
trois lignes suivantes sont identiques:
--name Un exemple
--name = un exemple
--name Un exemple
Si les fichiers d'argument contiennent des caractères non-ASCII, ils doivent être
enregistrés en utilisant le codage UTF-8.

Utiliser des fichiers d'argument

Les fichiers d'arguments peuvent être utilisés seuls pour contenir toutes les options
et les chemins d'accès aux données de test, ou associés à d'autres options et
chemins. Lorsqu'un fichier d'argument est utilisé avec d'autres arguments, son
contenu est placé dans la liste d'origine des arguments au même endroit que l'option
de fichier d'argument. Cela signifie que les options dans les fichiers d'arguments
peuvent remplacer les options avant celles-ci, et ses options peuvent être
remplacées par les options qui suivent. Il est possible d'utiliser l' option --
argumentfile plusieurs fois ou même récursivement:
robot --argumentfile all_arguments.robot
robot --name Exemple --argumentfile other_options_and_paths.robot
robot --argumentfile default_options.txt --name Exemple my_tests.robot
robot -A first.txt -A second.txt -A troisième.txt tests.robot

Lecture de fichiers d'arguments à partir d'une entrée standard

Un nom de fichier d'argument spécial STDINpeut être utilisé pour lire les arguments
du flux d'entrée standard au lieu d'un fichier. Cela peut être utile lors de la
génération d’arguments avec un script:
generate_arguments.sh | robot --argumentfile STDIN
generate_arguments.sh | robot --name Exemple --argumentfile STDIN
tests.robot

3.1.6 Obtenir de l'aide et des informations de version

Lors de l'exécution de scénarios de test et lors du post-traitement des sorties, il est
possible d'obtenir l'aide de la ligne de commande avec l'option --help (-
h) . Ces textes d'aide ont une courte vue d'ensemble et expliquent brièvement les
options de ligne de commande disponibles.

Tous les scripts de coureurs prennent également en charge l'obtention des

informations de version avec l'option --version . Cette information contient
également la version Python ou Jython et le type de plate-forme:
$ robot --version
Framework Robot 3.0 (Jython 2.7.0 sur java1.7.0_45)

C: \> rebot --version

Rebot 3.0 (Python 2.7.10 sur win32)

3.1.7 Création de scripts de démarrage

Les cas de test sont souvent exécutés automatiquement par un système d'intégration
continue ou par un autre mécanisme. Dans de tels cas, il est nécessaire d’avoir un
script pour lancer l’exécution du test, et éventuellement pour le post-traitement des
sorties. Des scripts similaires sont également utiles lors de l'exécution manuelle de
tests, en particulier si un grand nombre d'options de ligne de commande est
nécessaire ou si la configuration de l'environnement de test est compliquée.

Dans les environnements de type UNIX, les scripts shell constituent un mécanisme
simple mais puissant pour créer des scripts de démarrage personnalisés. Les
fichiers batch Windows peuvent également être utilisés, mais ils sont plus limités et
souvent plus compliqués. Une alternative indépendante de la plate-forme utilise
Python ou un autre langage de programmation de haut niveau. Indépendamment de
la langue, il est recommandé d'utiliser des noms d'option longs, car ils sont plus
faciles à comprendre que les noms abrégés.

Dans les premiers exemples, les mêmes tests Web sont exécutés avec différents
navigateurs et les résultats sont ensuite combinés. C'est facile avec les scripts shell,
car pratiquement vous ne listez que les commandes nécessaires:
#! / bin / bash
robot --variable BROWSER: Firefox --name Firefox --log none --report none -
-output out / fx.xml login
robot --variable BROWSER: IE --name IE --log none --report none --output
out / ie.xml login
rebot --name Login --outputdir --output login.xml out / fx.xml out / ie.xml

L'implémentation de l'exemple ci-dessus avec des fichiers batch Windows n'est pas
très compliqué non plus. La chose la plus importante à retenir est que, comme
les scripts de robot et de rebot sont implémentés en tant que fichiers de
commandes sous Windows, l' appel doit être utilisé lors de leur exécution à partir
d'un autre fichier de commandes. Sinon, l'exécution se terminerait lorsque le
premier fichier de commandes est terminé.
@ echo off
call robot --variable BROWSER: Firefox --name Firefox --log none --report
none --output out \ fx.xml connexion
robot d' appel - variable BROWSER: IE --name IE --log none - signaler
aucun --output out \ ie.xml appel de connexion
rebot --name Login --outputdir --output login.xml out \ fx.xml out \
ie.xml

Dans les exemples suivants, les fichiers jar sous le répertoire lib sont placés
dans CLASSPATH avant de lancer l'exécution du test. Dans ces exemples, les scripts
de démarrage exigent que les chemins vers les données de test exécutées soient
fournis en tant qu’arguments. Il est également possible d'utiliser les options de ligne
de commande librement, même si certaines options ont déjà été définies dans le
script. Tout cela est relativement simple en utilisant bash:
#! / bin / bash
cp = .
pour pot dans lib / *. jar ; faire
cp = $ cp : pot $
fait
export CLASSPATH = $ cp

robot --uputdir / tmp / logs --suitestatlevel 2 $ *

L'implémentation à l'aide de fichiers de commandes Windows est légèrement plus

compliquée. La partie difficile consiste à définir la variable contenant les fichiers
JAR nécessaires dans une boucle For, car, pour une raison quelconque, cela n'est
pas possible sans une fonction d'assistance.
@ Echo off

définir CP = .
pour %% jar dans ( lib \ *. jar ) do (
appel : set_cp %% jar
)
set CLASSPATH = % CP%

robot --uputdir c: \ temp \ logs --suitestatlevel 2 % *

goto : eof

:: aide pour la définition des variables dans une boucle for

: set_cp
set CP = % CP% ; % 1
goto : eof

Modification des paramètres de démarrage de Java

Parfois, lorsque vous utilisez Jython, il est nécessaire de modifier les paramètres de
démarrage de Java. Le cas d'utilisation le plus courant est l'augmentation de la taille
de mémoire maximale de la JVM car la valeur par défaut peut ne pas être suffisante
pour créer des rapports et des journaux lorsque les sorties sont très volumineuses. Il
existe deux méthodes simples pour configurer les options JVM:

1. Définissez la variable d'environnement JYTHON_OPTS . Cela peut être fait en

permanence au niveau du système d'exploitation ou par exécution dans un
script de démarrage personnalisé.
2. Transmettez les paramètres Java nécessaires avec l' option -J à Jython qui
les transmettra à Java. Ceci est particulièrement facile lors de
l' exécution directe du module robot installé :
3. Jython -J-Xmx1024m -m robot tests.robot

3.1.8 Problèmes de débogage

Un cas de test peut échouer car le système testé ne fonctionne pas correctement,
auquel cas le test a détecté un bogue ou parce que le test lui-même est bogué. Le
message d'erreur expliquant l'échec apparaît sur la sortie de la ligne de commande et
dans le fichier de rapport. Parfois, le message d'erreur suffit à identifier le
problème. Le plus souvent, toutefois, les fichiers journaux sont nécessaires car ils
contiennent également d'autres messages de journal et indiquent quel mot clé a
réellement échoué.

Lorsqu'une défaillance est provoquée par l'application testée, le message d'erreur et

les messages du journal doivent être suffisants pour comprendre la cause. Si ce
n'est pas le cas, la bibliothèque de tests ne fournit pas suffisamment d'informations et
doit être améliorée. Dans cette situation, exécuter manuellement le même test, si
possible, peut également révéler plus d'informations sur le problème.

Les échecs causés par les cas de test eux-mêmes ou par les mots-clés qu'ils utilisent
peuvent parfois être difficiles à déboguer. Si le message d'erreur, par exemple,
indique qu'un mot clé est utilisé avec un nombre incorrect d'arguments, le problème
est évidemment facile, mais si un mot clé est manquant ou échoue de manière
inattendue, trouver la cause peut être plus difficile. Le premier endroit pour
rechercher plus d'informations est la section des erreurs d'exécution dans le fichier
journal. Par exemple, une erreur concernant une importation de bibliothèque de test
ayant échoué peut bien expliquer pourquoi un test a échoué en raison d'un mot clé
manquant.

Si le fichier journal ne fournit pas suffisamment d'informations par défaut, il est

possible d'exécuter des tests avec un niveau de journalisation inférieur . Par exemple,
les traces indiquant l'emplacement de l'échec dans le code sont consignées dans
le DEBUGniveau, et cette information est inestimable lorsque le problème se trouve
dans un mot clé de bibliothèque individuel.

Les retraites enregistrées ne contiennent pas d'informations sur les méthodes à

l'intérieur de Robot Framework. Si vous pensez qu'une erreur est due à un bogue
dans la structure, vous pouvez activer l'affichage des traces internes en définissant
la variable d'environnement ROBOT_INTERNAL_TRACES sur une valeur non vide. Cette
fonctionnalité est nouvelle dans Robot Framework 2.9.2.

Si le fichier journal ne contient toujours pas suffisamment d'informations, il est

conseillé d'activer le journal système et de voir quelles informations il fournit. Il est
également possible d'ajouter des mots-clés aux cas de test pour voir ce qui se
passe. Surtout BuiltIn mots - clés Se connecter et Se connecter Les variables sont
utiles. Si rien d'autre ne fonctionne, il est toujours possible de rechercher de l'aide à
partir de listes de diffusion ou ailleurs.

Utilisation du débogueur Python (pdb)

Il est également possible d'utiliser le module pdb de la bibliothèque standard Python
pour définir un point d'arrêt et déboguer interactivement un test en cours
d'exécution. La manière typique d'invoquer pdb en insérant:
import pdb ; pdb . set_trace ()

à l'emplacement que vous souhaitez utiliser, le débogueur ne fonctionnera pas

correctement avec Robot Framework, car le flux de sortie standard est redirigé
pendant l'exécution du mot clé. Au lieu de cela, vous pouvez utiliser les éléments
suivants:
import sys , pdb ; pdb . Pdb ( stdout = sys . __Stdout__ ) . set_trace
()

à partir d'une bibliothèque python ou alternativley:

Evaluez pdb.Pdb (stdout = sys .__ stdout __). Set_trace () modules = sys,
pdb

peut être utilisé directement dans un cas de test.

3.2 Exécution du test

Cette section décrit comment la structure de la suite de tests créée à partir des
données de test analysées est exécutée, comment continuer à exécuter un scénario
de test après des échecs et comment arrêter correctement l'exécution du test.

 3.2.1 Flux d'exécution

o Suites et tests exécutés
o Configurations et démontages
o Ordre d'exécution
o Passer l'exécution
 3.2.2 Continuer en cas d'échec
o Exécuter des mots clés et ignorer les erreurs et exécuter les mots
clés et les erreurs attendues
o Défaillances spéciales des mots-clés
o Exécuter les mots - clés et continuer en cas d' échec mot - clé
o L'exécution se poursuit automatiquement lors des démontages
o Tous les mots-clés de niveau supérieur sont exécutés lorsque les tests ont
des modèles
 3.2.3 Arrêter l'exécution du test normalement
o Pressage Ctrl-C
o Utiliser des signaux
o En utilisant des mots-clés
o Arrêt lorsque le premier test échoue
o Arrêt sur analyse ou erreur d'exécution
o Manipulation des démontages
3.2.1 Flux d'exécution
Suites et tests exécutés
Les cas de test sont toujours exécutés dans une suite de tests. Une suite de tests
créée à partir d'un fichier de scénario de test dispose de tests directs, tandis que les
suites créées à partir de répertoiresdisposent de suites de tests enfants qui possèdent
des tests ou leurs propres suites enfants. Par défaut, tous les tests d'une suite
exécutée sont exécutés, mais il est possible de sélectionner des tests à l'aide des
options --test , --suite , --include et --exclude . Les suites ne
contenant aucun test sont ignorées.

L'exécution commence à partir de la suite de tests de niveau supérieur. Si la suite a

des tests, ils sont exécutés un par un et, s’il a des suites, ils sont exécutés
récursivement en profondeur au premier ordre. Lorsqu'un cas de test individuel est
exécuté, les mots-clés qu'il contient sont exécutés dans une
séquence. Normalement, l'exécution du test en cours se termine si l'un des mots
clés échoue, mais il est également possible de continuer après des échecs . L' ordre
d'exécution exact et la manière dont les configurations et les
démontages possibles affectent l'exécution sont décrits dans les sections suivantes.

Configurations et démontages
Et démontages setups peuvent être utilisés sur la suite de tests , cas de test et mot - clé
utilisateur niveaux.

Configuration de la suite

Si une suite de tests a une configuration, elle est exécutée avant ses tests et ses
suites enfants. Si la configuration de la suite est réussie, l'exécution du test se
poursuit normalement. En cas d'échec, tous les scénarios de test contenus dans la
suite et ses suites enfants sont marqués comme ayant échoué. Les tests et les
configurations et démontages de suites possibles dans les suites de tests enfants ne
sont pas exécutés.

Les configurations de suite sont souvent utilisées pour configurer l'environnement

de test. Les tests n'étant pas exécutés en cas d'échec de l'installation de la suite, il
est facile d'utiliser les configurations de la suite pour vérifier que l'environnement
est en état dans lequel les tests peuvent être exécutés.

Démontage de la suite

Si une suite de tests a un démontage, elle est exécutée après tous les cas de test et
suites enfants. Les démontages de suites sont exécutés quel que soit l'état du test et
même si l'installation de la suite correspondante échoue. Si le démontage de la suite
échoue, tous les tests de la suite sont marqués comme ayant échoué par la suite
dans les rapports et les journaux.

Les démontages de suites sont principalement utilisés pour nettoyer

l'environnement de test après l'exécution. Pour vous assurer que toutes ces tâches
sont effectuées, tous les mots-clés utilisés dans le démontage sont exécutés même si
certains échouent.

Configuration du test

La configuration de test possible est exécutée avant les mots-clés du scénario de

test. Si la configuration échoue, les mots-clés ne sont pas exécutés. L'utilisation
principale des configurations de test consiste à configurer l'environnement pour ce
cas de test particulier.

Test de démontage

Le démontage de test possible est exécuté après l'exécution du scénario de test. Il

est exécuté quel que soit l'état du test et également si la configuration du test a
échoué.

De même que le démontage des suites, les démontages de tests sont principalement
utilisés pour les activités de nettoyage. Ils sont également exécutés complètement
même si certains de leurs mots-clés échouent.

Démontage du mot clé

Les mots-clés utilisateur ne peuvent pas avoir de configuration, mais ils peuvent
comporter des démontages qui fonctionnent exactement comme les autres
démontages. Les démontages de mots-clés sont exécutés après l'exécution du mot-
clé, quel que soit son état, et ils sont exécutés complètement même si certains de
leurs mots-clés échouent.

Ordre d'exécution
Les scénarios de test dans une suite de tests sont exécutés dans le même ordre qu'ils
sont définis dans le fichier de scénario de test. Les suites de tests à l'intérieur d'une
suite de tests de niveau supérieur sont exécutées dans un ordre alphabétique non
sensible à la casse basé sur le nom du fichier ou du répertoire. Si plusieurs fichiers
et / ou répertoires sont donnés à partir de la ligne de commande, ils sont exécutés
dans l'ordre indiqué.

S'il est nécessaire d'utiliser certains ordres d'exécution de suites de tests dans un
répertoire, il est possible d'ajouter des préfixes tels que 01 et 02 dans les noms de
fichiers et de répertoires. Ces préfixes ne sont pas inclus dans le nom de la suite de
tests générée s'ils sont séparés du nom de base de la suite par deux traits de
soulignement:
01__my_suite.html -> Ma suite
02__another_suite.html -> Une autre suite

Si l'ordre alphabétique des suites de tests à l'intérieur des suites pose problème, une
bonne solution consiste à les donner séparément dans l'ordre requis. Cela conduit
facilement à des commandes de démarrage trop longues, mais les fichiers
d'argument permettent de classer les fichiers de manière agréable sur un fichier par
ligne.

Il est également possible de randomiser l'ordre d'exécution en utilisant l' option --

randomize .

Passer l'exécution
Généralement, les cas de test, les configurations et les démontages sont considérés
comme réussis si tous les mots-clés qu'ils contiennent sont exécutés et qu'aucun
d'entre eux n'échoue. À partir de Robot Framework 2.8, il est également possible
d'utiliser les mots-clés intégrés dans la section Exécution et exécution du passage pour
arrêter l'exécution avec le statut PASS et ignorer les mots-clés restants.

La procédure d'exécution des passes et l' exécution des passes si elles se

comportent dans différentes situations sont expliquées ci-dessous:

 Lorsqu'ils sont utilisés dans une configuration ou une suppression (suite, test ou
mot-clé), ces mots-clés réussissent cette configuration ou cette
suppression. Les démontages possibles des mots-clés démarrés sont
exécutés. L'exécution du test ou les statuts ne sont pas affectés autrement.
 Lorsqu'ils sont utilisés dans un scénario de test en dehors de la configuration
ou du démontage, les mots-clés réussissent ce cas de test particulier. Les
tests possibles et les démontages de mots-clés sont exécutés.
 Les défaillances possibles pouvant survenir avant que ces mots-clés ne soient
utilisés, ainsi que les défaillances lors des démontages exécutés par la suite,
échoueront à l'exécution.
 Il est obligatoire de donner un message expliquant pourquoi l'exécution a été
interrompue et il est également possible de modifier les balises de test
élémentaire. Pour plus de détails et des exemples d'utilisation, consultez
la documentation de ces mots clés .

Passer l’exécution au milieu d’un test, d’une configuration ou d’un démontage doit
être utilisé avec précaution. Dans le pire des cas, cela conduit à des tests qui
ignorent toutes les pièces susceptibles de révéler des problèmes dans l’application
testée. Dans les cas où l'exécution ne peut pas continuer sur des facteurs externes, il
est souvent plus sûr d'échouer le test élémentaire et de le rendre non critique .

3.2.2 Continuer en cas d'échec

Normalement, les cas de test sont arrêtés immédiatement lorsque l'un de leurs mots
clés échoue. Ce comportement réduit le temps d'exécution des tests et empêche les
mots-clés ultérieurs de se bloquer ou de causer des problèmes si le système testé est
en état instable. Cela a l'inconvénient que souvent les mots-clés suivants
donneraient plus d'informations sur l'état du système. Par conséquent, Robot
Framework offre plusieurs fonctionnalités à poursuivre après des échecs.

Exécuter des mots clés et ignorer les erreurs et exécuter les mots clés
et les erreurs attendues
Mots clés intégrés Exécuter le mot clé et ignorer les erreurs et exécuter le mot clé et
les erreurs attendues gèrent les échecs afin que l'exécution du test ne soit pas
terminée immédiatement. Bien que l'utilisation de ces mots clés à cette fin ajoute
souvent une complexité supplémentaire aux cas de test, les fonctionnalités
suivantes méritent d'être prises en compte pour faciliter la poursuite des échecs.

Défaillances spéciales des mots-clés

Les mots-clés de la bibliothèque signalent les échecs à l'aide d'exceptions, et il est
possible d'utiliser des exceptions spéciales pour indiquer à l'infrastructure de base
que l'exécution peut continuer malgré l'échec. La manière dont ces exceptions
peuvent être créées est expliquée dans le chapitre API de la bibliothèque de tests .

Lorsqu'un test se termine et qu'il y a eu un ou plusieurs échecs continus, le test

échoue. S'il y a plus d'un échec, ils seront tous énumérés dans le message d'erreur
final:
Plusieurs échecs ont eu lieu:

1) Premier message d'erreur.

2) Deuxième message d'erreur ...

L'exécution du test se termine également si une défaillance normale se produit

après des défaillances permanentes. Dans ce cas également, tous les échecs seront
répertoriés dans le message d'erreur final.

La valeur de retour des mots clés en échec, éventuellement attribués à une variable,
est toujours le Python None.

Exécuter les mots - clés et continuer en cas d' échec mot - clé
Mot- clé intégré Exécuter un mot- clé et continuer en cas d'échec permet de
convertir toute défaillance en une défaillance continue. Ces échecs sont traités par
le framework de la même manière que les échecs continus provenant des mots-clés
de la bibliothèque.

L'exécution se poursuit automatiquement lors des démontages

Pour être sûr que toutes les activités de nettoyage sont prises en charge, le mode
continuer en cas d'échec est automatiquement activé lors des tests et des démontages
de suites. . En pratique, cela signifie que dans les démontages, tous les mots-clés à
tous les niveaux sont toujours exécutés.

Tous les mots-clés de niveau supérieur sont exécutés lorsque les

tests ont des modèles
Lors de l'utilisation de modèles de test , toutes les lignes de données sont toujours
exécutées pour s'assurer que toutes les combinaisons sont testées. Dans cette
utilisation, la poursuite est limitée aux mots-clés de niveau supérieur, et à l'intérieur
de ceux-ci, l'exécution se termine normalement s'il existe des défaillances
ininterrompues.

3.2.3 Arrêter l'exécution du test normalement

Parfois, il est nécessaire d'arrêter l'exécution du test avant que tous les tests ne
soient terminés, mais pour que les journaux et les rapports soient créés. Différentes
manières d'accomplir ceci sont expliquées ci-dessous. Dans tous ces cas, les cas de
test restants sont marqués comme ayant échoué.

À partir de Robot Framework 2.9, les tests qui échouent automatiquement

obtiennent une robot-exitbalise et le rapport généré inclut NOT robot-exit un
modèle de balise combiné pour voir facilement les tests qui n'ont pas été
ignorés. Notez que le test dans lequel la sortie s'est produite ne reçoit pas la robot-
exitbalise.

Remarque

Le préfixe utilisé avec les balises réservées est susceptible d'être modifié à robot:l'avenir, ce
qui signifie que la robot-exitbalise sera renommée. Voir le numéro 2539 pour plus de
détails.

Pressage Ctrl-C
L'exécution est arrêtée lorsque vous Ctrl-Cappuyez sur la console où les tests sont
en cours d'exécution. Lors de l'exécution des tests sur Python, l'exécution est
arrêtée immédiatement, mais avec Jython, elle ne se termine qu'après la fin du mot
clé en cours d'exécution.

Si vous Ctrl-Cappuyez à nouveau sur, l'exécution se termine immédiatement et les

rapports et les journaux ne sont pas créés.

Utiliser des signaux

Sur les machines de type Unix, il est possible de terminer l'exécution du test en
utilisant des signaux INTet TERM. Ces signaux peuvent être envoyés depuis la ligne
de commande à l'aide de la commande kill , et l'envoi de signaux peut également
être facilement automatisé.

Les signaux ont la même limitation sur Jython que sur appuyer Ctrl-C. De même,
le deuxième signal arrête l'exécution avec force.

En utilisant des mots-clés

L'exécution peut également être interrompue par les mots-clés exécutés. Il existe
un mot-clé Fatal Error BuiltIn distinct et les mots-clés personnalisés peuvent
utiliser des exceptions fatales lorsqu'ils échouent.

Arrêt lorsque le premier test échoue

Si l'option --exitonfailure (-X) est utilisée, l'exécution du test s'arrête
immédiatement si un test critique échoue. Les tests restants sont marqués comme
ayant échoué sans être réellement exécutés.

Remarque

L'option courte -X est nouvelle dans Robot Framework 3.0.1.

Arrêt sur analyse ou erreur d'exécution

Robot Framework sépare les défaillances causées par des mots clés défaillants
des erreurs provoquées, par exemple, par des paramètres non valides ou des
importations de bibliothèques de tests ayant échoué. Par défaut, ces erreurs sont
signalées comme des erreurs d'exécution de test , mais les erreurs elles-mêmes
n'échouent pas les tests ou n'affectent pas l'exécution. Si l' option --
exitonerror est utilisée, toutes ces erreurs sont considérées comme fatales et
l'exécution est interrompue pour que les tests restants soient marqués comme ayant
échoué. Avec les erreurs d'analyse rencontrées avant même que l'exécution ne
commence, cela signifie qu'aucun test n'est réellement exécuté.

Remarque
--exitonerror est nouveau dans Robot Framework 2.8.6.

Manipulation des démontages

Par défaut, les démontages des tests et des suites lancés sont exécutés même si
l'exécution du test est arrêtée à l'aide de l'une des méthodes ci-dessus. Cela permet
d'exécuter des activités de nettoyage, quelle que soit la fin de l'exécution.

Il est également possible d'ignorer les démontages lorsque l'exécution est arrêtée à
l'aide de l' option --skipteardownonexit . Cela peut être utile si, par
exemple, les tâches de nettoyage prennent beaucoup de temps.

3.3 Résultats du post-traitement

Les fichiers de sortie XML générés lors de l'exécution du test peuvent être post-traités
ultérieurement par l'outil Rebot, qui fait partie intégrante de Robot Framework. Il
est utilisé automatiquement lorsque des rapports de test et des journaux sont
générés pendant l'exécution du test. Son utilisation séparée permet de créer des
rapports et des journaux personnalisés, ainsi que de combiner et de fusionner les
résultats.

 3.3.1 Utilisation de Rebot

o Synopsis
o Spécification des options et des arguments
o Codes de retour avec Rebot
 3.3.2 Création de différents rapports et journaux
 3.3.3 Combinaison des sorties
 3.3.4 Fusion des sorties
o Fusion de tests ré-exécutés
o Suites fusionnées exécutées en morceaux

3.3.1 Utilisation de Rebot

Synopsis
rebot [options] robot_outputs
python | jython | ipy -m robot.rebot [options] robots_outputs
python | jython | chemin ipy / to / robot / rebot.py [options]
robot_outputs
java -jar robotframework.jar rebot [options] robots_outputs

La méthode la plus courante pour utiliser Rebot consiste à utiliser le script

runner rebot . Il est également possible d'exécuter le module robot.rebot ou le fichier
robot / rebot.py installé directement à l'aide de l'interpréteur sélectionné. La dernière
solution consiste à utiliser la distribution JAR autonome .

Remarque
Les versions antérieures à Robot Framework 3.0 n'installaient le script rebot qu'avec
Python et utilisaient respectivement des scripts jyrebot et ipyrebot avec Jython et
IronPython. Ces scripts sont toujours installés, mais il est prévu de les déprécier et de les
supprimer ultérieurement.

Spécification des options et des arguments

La syntaxe de base pour utiliser Rebot est exactement la même que lors
du démarrage de l'exécution du test et la plupart des options de la ligne de commande
sont identiques. La principale différence est que les arguments de Rebot sont des
fichiers de sortie XML plutôt que des fichiers de données de test ou des répertoires.

Codes de retour avec Rebot

Les codes de retour de Rebot sont exactement les mêmes que lors de l' exécution des
tests .

3.3.2 Création de différents rapports et journaux

Vous pouvez utiliser Rebot pour créer les mêmes rapports et journaux créés
automatiquement lors de l'exécution du test. Bien sûr, il n’est pas judicieux de créer
exactement les mêmes fichiers, mais, par exemple, il peut être utile d’avoir un
rapport avec tous les scénarios de test et un autre avec seulement un sous-ensemble
de tests:
rebot output.xml
rebot path / to / output_file.xml
rebot --include smoke --name Smoke_Tests c: \ results \ output.xml

Une autre utilisation courante est la création du fichier de sortie uniquement lors de
l'exécution de tests (la --log NONE --report NONEgénération de journaux et de
rapports peut être désactivée avec ) et la génération de journaux et de rapports
ultérieurement. Les tests peuvent, par exemple, être exécutés sur des
environnements différents, des fichiers de sortie collectés dans un emplacement
central, des rapports et des journaux créés à cet endroit. Cette approche peut
également fonctionner très bien si la génération de rapports et de journaux prend
beaucoup de temps lors de l'exécution de tests sur Jython. La désactivation de la
génération de rapports et de rapports et leur génération ultérieure avec Rebot
permettent de gagner beaucoup de temps et d'utiliser moins de mémoire.

3.3.3 Combinaison des sorties

Une fonctionnalité importante de Rebot est sa capacité à combiner les sorties de
différents cycles d’exécution de tests. Cette fonctionnalité permet, par exemple,
d'exécuter les mêmes scénarios de test sur des environnements différents et de
générer un rapport global à partir de toutes les sorties. La combinaison des sorties
est extrêmement simple, il suffit de donner plusieurs fichiers de sortie en
arguments:
rebot output1.xml output2.xml
rebot output / *. xml

Lorsque les sorties sont combinées, une nouvelle suite de tests de niveau supérieur
est créée afin que les suites de tests des fichiers de sortie donnés soient ses suites
enfants. Cela fonctionne de la même manière lorsque plusieurs fichiers ou répertoires
de données de test sont exécutés , et dans ce cas également, le nom de la suite de tests
de niveau supérieur est créé en joignant des noms de suites enfants avec une
perluète (&) et des espaces. Ces noms générés automatiquement ne sont pas très
bons et c'est souvent une bonne idée d'utiliser --name pour donner un nom plus
significatif:
rebot --name Browser_Compatibility firefox.xml opera.xml safari.xml
ie.xml
rebot --include smoke --name Smoke_Tests c: \ results \ *. xml

3.3.4 Fusion des sorties

Si les mêmes tests sont ré-exécutés ou si une suite de tests unique est exécutée en
plusieurs parties, la combinaison des résultats comme indiqué ci-dessus crée une
suite de tests de niveau supérieur inutile. Dans ces cas, il est généralement
préférable de fusionner les résultats à la place. La fusion est effectuée à l'aide de
l' option --merge (-R) , qui modifie la manière dont Rebot combine deux
fichiers de sortie ou plus. Cette option ne prend aucun argument et toutes les autres
options de ligne de commande peuvent être utilisées avec elle normalement:
rebot --merge --name Exemple - régression critique original.xml
merged.xml

La façon dont la fusion fonctionne dans la pratique est expliquée dans les sections
suivantes traitant de ses deux principaux cas d'utilisation.

Fusion de tests ré-exécutés

Il est souvent nécessaire de ré-exécuter un sous-ensemble de tests, par exemple,
après avoir corrigé un bogue dans le système testé ou dans les tests eux-
mêmes. Cela peut être accompli en sélectionnant des cas de test par noms ( options --
test et --suite ), tags ( --include et --exclude ), ou par statut précédent
( --rerunfailed ou --rerunfailedsuites ).

La combinaison des résultats de ré-exécution avec les résultats originaux en

utilisant l’ approche de combinaison par défaut ne fonctionne pas bien. Le principal
problème est que vous obtenez des suites de tests distinctes et que des échecs
éventuellement déjà corrigés sont également affichés. Dans cette situation, il est
préférable d'utiliser l' option --merge (-R) pour indiquer à Rebot de
fusionner les résultats à la place. En pratique, cela signifie que les tests de ce
dernier test remplacent les tests de l'original. Un exemple pratique d'utilisation --
rerunfailed et --merge :
tests de robot --output original.xml # exécuter tout d'abord tous les
tests
robot --rerunfailed original.xml --output rerun.xml teste # puis ré-
exécute l'échec
rebot --merge original.xml rerun.xml # fusionne enfin les résultats

Le message des tests fusionnés contient une note indiquant que les résultats ont été
remplacés. Le message indique également l’ancien statut et le message du test.

Les résultats fusionnés doivent toujours avoir la même suite de tests de niveau
supérieur. Les tests et les suites dans les sorties fusionnées qui ne sont pas trouvées
dans la sortie d'origine sont ajoutés dans la sortie résultante. Comment cela
fonctionne-t-il dans la section suivante.

Remarque

La fusion des résultats ré-exécutés est une nouvelle fonctionnalité de Robot Framework
2.8.4. Avant Robot Framework 2.8.6, de nouveaux tests ou suites dans les sorties fusionnées
ont été ignorés et la fusion a été effectuée à l'aide de l' option --rerunmerge .

Suites fusionnées exécutées en morceaux

Un autre cas d'utilisation important de l' option --merge est la fusion des résultats
obtenus lors de l'exécution d'une suite de tests en utilisant, par exemple,
les options --include et --exclude :
robot --include smoke --output smoke.xml test # lance d'abord des
tests
robot --exclude smoke --output others.xml test # puis lance les autres
rebot --merge smoke.xml others.xml # fusionne enfin les résultats

Lors de la fusion de sorties comme celle-ci, la sortie résultante contient tous les
tests et suites trouvés dans tous les fichiers de sortie donnés. Si un test est trouvé à
partir de plusieurs sorties, les derniers résultats remplacent les précédents, comme
expliqué dans la section précédente. Cette stratégie de fusion exige également que
les suites de tests de niveau supérieur soient identiques dans toutes les sorties.

3.4 Configuration de l'exécution

Cette section explique différentes options de ligne de commande pouvant être
utilisées pour configurer l' exécution des tests ou les post-traitements . Les options
relatives aux fichiers de sortie générés sont traitées dans la section suivante .
  3.4.1 Sélection des fichiers à analyser
 3.4.2 Sélection des cas de test
o Par suite de tests et noms de cas de test
o Par noms de tags
o Ré-exécution des cas de test ayant échoué
o Ré-exécution des suites de tests ayant échoué
o Quand aucun test ne correspond à la sélection
 3.4.3 Définition de la criticité
 3.4.4 Définition des métadonnées
o Définition du nom
o Définition de la documentation
o Définition de métadonnées gratuites
o Définition des balises
 3.4.5 Configuration de la recherche des bibliothèques et autres extensions
o Emplacements automatiquement dans le chemin de recherche des modules
o PYTHONPATH , JYTHONPATH et IRONPYTHONPATH
o En utilisant l' --pythonpathoption
o Configuration par sys.pathprogrammation
o Java classpath
 3.4.6 Définition des variables
 3.4.7 Course à sec
 3.4.8 Ordre d'exécution aléatoire
 3.4.9 Modification programmatique des données de test
o Exemple: sélectionnez tous les X tests
o Exemple: Exclure les tests par nom
o Exemple: Ignorer les configurations et les démontages
 3.4.10 Contrôle de la sortie de la console
o Type de sortie de la console
o Largeur de la console
o Couleurs de la console
o Marqueurs de console
 3.4.11 Réglage des écouteurs

3.4.1 Sélection des fichiers à analyser

Robot Framework prend en charge les données de test dans différents formats , mais
de nos jours, le format de texte brut dans les *.robotfichiers dédiés est le plus
couramment utilisé. Si un seul format de fichier est utilisé dans un projet, il peut
être judicieux de limiter les données de test d'analyse uniquement à ces fichiers à
l'aide de l' option --extension (-F) . Ceci est particulièrement utile si le
répertoire exécuté contient des fichiers volumineux ne contenant pas de données de
test, mais qui ont une extension que Robot Framework analyserait autrement. En
particulier, les fichiers HTML volumineux, tels que les rapports et les journaux que
vous pouvez obtenir depuis Robot Framework, peuvent être assez longs à traiter.

L' option --extension prend une extension de fichier comme argument et seuls
les fichiers portant cette extension sont analysés. Cela n'a toutefois d'effet que lors
de l'exécution de répertoires, pas lors de l'exécution de fichiers individuels spécifiés
explicitement. Cela n'affecte pas non plus les fichiers pouvant être utilisés
comme fichiers de ressources . S'il est nécessaire d'analyser plusieurs types de
fichiers, il est possible d'utiliser deux points :pour séparer les extensions. Les
extensions correspondantes ne sont pas sensibles à la casse.
robot --extension chemin du robot / à / tests
robot --extension ROBOT: chemin TXT / to / tests

Si des fichiers dans un format utilisent des extensions différentes comme *

.html et * .htm , vous devez spécifier ces extensions séparément. L'utilisation d'un
seul d'entre eux signifierait que d'autres fichiers dans ce format sont ignorés.

Remarque

La sélection de fichiers à analyser est une nouvelle fonctionnalité de Robot Framework 3.0.1.

3.4.2 Sélection des cas de test

Robot Framework offre plusieurs options de ligne de commande pour sélectionner
les scénarios de test à exécuter. Les mêmes options fonctionnent également lors du
post-traitement des sorties avec Rebot .

Par suite de tests et noms de cas de test

Les suites de tests et les cas de test peuvent être sélectionnés par leurs noms avec
les options de ligne de commande --suite (-s) et --test (-t) ,
respectivement. Ces deux options peuvent être utilisées plusieurs fois pour
sélectionner plusieurs suites de tests ou cas. Les arguments en faveur de ces options
sont insensibles à la casse et à l’espace, et il peut également y avoir des motifs
simples correspondant à plusieurs noms. Si les options --suite et --test sont
utilisées, seuls les scénarios de test dans les suites correspondantes avec des
noms correspondants sont sélectionnés.
--exemple de test
--test mytest --test yourtest
--test exemple *
--test mysuite.mytest
--test * .suite.mytest
--suite exemple- ??
--suite mysuite --test mytest --test votre *

Utiliser l' option --suite est plus ou moins la même chose que d'exécuter
uniquement le fichier ou le répertoire du scénario de test approprié. Un
avantage majeur est la possibilité de sélectionner la suite en fonction de sa suite
parentale. La syntaxe de ce paramètre spécifie les noms de suite parent et enfant
séparés par un point. Dans ce cas, la configuration et le démontage possibles de la
suite parent sont exécutés.
 --suite parent.child
--suite myhouse.myhousemusic --test jack *

La sélection de scénarios de test individuels avec l' option --test est très
pratique lors de la création de scénarios de test, mais assez limitée lors de
l'exécution automatique de tests. L' option --suite peut être utile dans ce cas,
mais en général, la sélection de cas de test par nom de tag est plus flexible.

Par noms de tags

Il est possible d'inclure et d'exclure des scénarios de test par noms
de balises avec les options --include (-i) et --exclude (-
e) respectivement. Si l' option --include est utilisée, seuls les cas de test ayant
une balise correspondante sont sélectionnés et, avec l' option --exclude , les cas
de test ayant une balise correspondante ne le sont pas. Si les deux sont utilisés,
seuls les tests avec une balise correspondant à l'ancienne option, et non avec une
balise correspondant à cette dernière, sont sélectionnés.
--include exemple
--exclude not_ready
--include la régression --exclude long_lasting

Les deux options --include et --exclude peuvent être utilisées plusieurs

fois pour correspondre à plusieurs balises. Dans ce cas, un test est sélectionné s'il
comporte une balise qui correspond à toute balise incluse et si aucune balise ne
correspond à une balise exclue.

En plus de spécifier une étiquette pour correspondre pleinement, il est possible

d'utiliser des modèles de balises où *et ?sont des jokers et AND, OR, et les NOTopérateurs
peuvent être utilisés pour combiner des étiquettes individuelles ou modèles
ensemble:
--include fonctionnalité-4?
--exclude bug *
--inclu fooANDbar
--exclure xxoryyorzz
--include fooNOTbar

La sélection de cas de test par balises est un mécanisme très flexible et offre de
nombreuses possibilités intéressantes:

 Un sous-ensemble de tests à exécuter avant d'autres tests, souvent appelés

tests de fumée, peut être étiqueté smokeet exécuté avec --include smoke.
 Un test inachevé peut être engagé dans le contrôle de version avec un tag tel
que not_readyet exclu de l'exécution du test avec --exclude not_ready.
 Les tests peuvent être balisés avec sprint-<num>, où <num>spécifie le numéro
du sprint en cours, et après l'exécution de tous les scénarios de test, un
 rapport distinct contenant uniquement les tests d'un certain sprint peut être
généré (par exemple rebot --include sprint-42 output.xml).

Ré-exécution des cas de test ayant échoué

L'option de ligne de commande --rerunfailed (-R) peut être utilisée pour
sélectionner tous les tests ayant échoué à partir d'un fichier de sortie antérieur en vue
d'une ré-exécution. Cette option est utile, par exemple, si l’exécution de tous les
tests prend beaucoup de temps et que l’on veut réparer de manière itérative les cas
de test défaillants.
tests robotiques # exécuter d'abord tous les tests
robot --rerunfailed output.xml test # puis ré-exécuter échec

Dans les coulisses, cette option sélectionne les tests ayant échoué car ils auraient
été sélectionnés individuellement avec l' option --test . Il est possible d'affiner la
liste des tests sélectionnés en utilisant les options --test , --suite , --
include et --exclude .

L'utilisation d'une sortie ne provenant pas de l'exécution des mêmes tests exécutés
entraîne désormais des résultats indéfinis. En outre, il s'agit d'une erreur si la sortie
ne contient aucun test échoué. Utiliser une valeur spéciale NONEcomme sortie
revient à ne pas spécifier cette option du tout.

Pointe

Les résultats de ré-exécution et les résultats originaux peuvent être fusionnés à l'aide de
l' option de ligne de commande --merge .

Remarque

Ré-exécuter les tests ayant échoué est une nouvelle fonctionnalité de Robot Framework
2.8. Avant Robot Framework 2.8.4, l'option était nommée --runfailed .

Ré-exécution des suites de tests ayant échoué

L'option de ligne de commande rerunfailedsuites (-S) peut être utilisée
pour sélectionner toutes les suites ayant échoué à partir d'un fichier de
sortie antérieur en vue d'une nouvelle exécution. Comme --rerunfailed (-
R) , cette option est utile lorsque l'exécution complète du test prend beaucoup de
temps. Notez que tous les tests d'une suite de tests ayant échoué seront ré-exécutés,
même ceux qui passent. Cette option est utile lorsque les tests d'une suite de tests
dépendent les uns des autres.

Dans les coulisses, cette option sélectionne les suites ayant échoué car elles
auraient été sélectionnées individuellement avec l' option --suite . Il est possible
d'affiner la liste des tests sélectionnés en utilisant les options --test , --
suite , --include et --exclude .

Remarque

L' option --rerunfailedsuites a été ajoutée dans Robot Framework 3.0.1.

Quand aucun test ne correspond à la sélection

Par défaut, si aucun test ne correspond, l'exécution du test des critères de sélection
échoue avec une erreur telle que:
[ERREUR] Suite 'Exemple' avec include 'xxx' ne contient aucun cas de
test.

Étant donné qu'aucune sortie n'est générée, ce comportement peut être

problématique si les tests sont exécutés et les résultats traités
automatiquement. Heureusement, une option de ligne de commande --
RunEmptySuite peut être utilisée pour forcer l'exécution de la suite également
dans ce cas. En conséquence, les sorties normales sont créées mais affichent des
tests exécutés à zéro. La même option peut également être utilisée pour modifier le
comportement lorsqu'un répertoire vide ou un fichier de scénario de test ne
contenant aucun test est exécuté.

Une situation similaire peut se produire lors du traitement des fichiers de sortie
avec Rebot . Il est possible qu'aucun test ne corresponde aux critères de filtrage
utilisés ou que le fichier de sortie ne contienne aucun test pour commencer. Par
défaut, l'exécution de Rebot échoue dans ces cas, mais elle comporte une option --
ProcessEmptySuite distincte qui peut être utilisée pour modifier le
comportement. En pratique, cette option fonctionne de la même manière que --
RunEmptySuite lors de l'exécution de tests.

Remarque

L' option --ProcessEmptySuite a été ajoutée dans Robot Framework 2.7.2.

3.4.3 Définition de la criticité

Le résultat final de l'exécution du test est déterminé sur la base de tests critiques. Si
un seul test critique échoue, l'ensemble du test est considéré comme ayant
échoué. En revanche, les cas de test non critiques peuvent échouer et le statut
global est toujours considéré comme réussi.

Tous les cas de test sont considérés comme critiques par défaut, mais cela peut être
modifié avec les options --critical (-c) et --noncritical (-
n) . Ces options spécifient quels tests sont critiques en fonction des balises , de la
même manière que --include et --exclude sont utilisés pour sélectionner des
tests par balises . Si seul --critical est utilisé, les cas de test avec une balise
correspondante sont critiques. Si seulement - non critique est utilisé, les tests
sans balise correspondante sont critiques. Enfin, si les deux sont utilisés, seuls les
tests avec une balise critique mais sans balise non critique sont critiques.

Les deux --critical et --noncritical supportent également les

mêmes modèles de balises que --include et --exclude . Cela signifie que
la recherche de motifs est le cas, l' espace, et soulignent insensible, *et ? sont pris
en charge comme des caractères génériques, et AND, ORet les NOT opérateurs peuvent
être utilisés pour créer des motifs combinés.
- régression critique
--noncritical not_ready
- iterique critique - * - req critique - * - req-6 non critique ??

Le cas d'utilisation le plus courant pour la définition de la criticité est d'avoir des
cas de test qui ne sont pas prêts ou de tester des fonctionnalités encore en cours
d'exécution dans l'exécution du test. Ces tests peuvent également être exclus de
l'exécution du test avec l' option --exclude , mais leur inclusion en tant que tests
non critiques vous permet de voir quand ils commencent à passer.

La criticité définie lors de l'exécution des tests n'est stockée nulle part. Si vous
souhaitez conserver la même criticité lors du post-traitement des sorties avec Rebot,
vous devez utiliser --critical et / ou --noncritical également avec:
# Utilisez rebot pour créer un nouveau journal et créer un rapport à
partir de la sortie créée lors de l'exécution
robot --régression critique --outputdir tous tests.robot
rebot --name Smoke --include smoke --critique regression --outputdir
smoke all / output.xml

# Pas besoin d'utiliser --critique / - non critique lorsque aucun

journal ou rapport n'est créé
robot --log NONE --report NONE tests.robot
rebot --critical feature1 output.xml

3.4.4 Définition des métadonnées

Définition du nom
Lorsque Robot Framework analyse les données de test, les noms des suites de tests
sont créés à partir des noms de fichiers et de répertoires . Le nom de la suite de tests de
niveau supérieur peut cependant être remplacé par l'option de ligne de commande -
-name (-N) . Les traits de soulignement dans le nom donné sont convertis
automatiquement en espaces.
Définition de la documentation
En plus de définir la documentation dans les données de test , la documentation de la
suite de niveau supérieur peut être fournie à partir de la ligne de commande avec
l'option --doc (-D) . Les traits de soulignement dans la documentation donnée
sont convertis en espaces et peuvent contenir un formatage HTML simple .

Définition de métadonnées gratuites

Des métadonnées de suite de test gratuites peuvent également être fournies à partir de la
ligne de commande avec l'option --metadata (-M) . L'argument doit être au
format name:value, où namele nom des métadonnées à définir et valuesa valeur. Les
caractères de soulignement dans le nom et la valeur sont convertis en espaces et ce
dernier peut contenir un formatage HTML simple . Cette option peut être utilisée
plusieurs fois pour définir plusieurs métadonnées.

Définition des balises

L'option de ligne de commande --settag (-G) peut être utilisée pour définir la
balise donnée sur tous les cas de test exécutés. Cette option peut être utilisée
plusieurs fois pour définir plusieurs balises.

3.4.5 Configuration de la recherche des bibliothèques et

autres extensions
Lorsque Robot Framework importe une bibliothèque de test , un écouteur ou une autre
extension basée sur Python, il utilise l'interpréteur Python pour importer le module
contenant l'extension du système. La liste des emplacements où les modules sont
recherchés est appelée chemin de recherche du module et son contenu peut être
configuré en utilisant différentes approches expliquées dans cette section. Lors de
l'importation de bibliothèques Java ou d'autres extensions sur Jython, Java
classpath est utilisé en plus du chemin de recherche de module normal.

Robot Framework utilise également le chemin de recherche de module de Python

lors de l'importation de fichiers de ressources et de variables si le chemin spécifié ne
correspond à aucun fichier directement.

Le chemin de recherche du module étant défini correctement pour que les

bibliothèques et les autres extensions soient détectées, il est nécessaire d’exécuter
les tests avec succès. Si vous avez besoin de le personnaliser en utilisant les
approches expliquées ci-dessous, il est souvent utile de créer un script de
démarrage personnalisé .
Emplacements automatiquement dans le chemin de recherche des
modules
Les interpréteurs Python ont leur propre bibliothèque standard ainsi qu'un
répertoire dans lequel les modules tiers sont installés automatiquement dans le
chemin de recherche du module. Cela signifie que les bibliothèques de
test conditionnées à l'aide du système de packaging de Python sont automatiquement
installées pour pouvoir être importées sans aucune configuration supplémentaire.

PYTHONPATH , JYTHONPATH et IRONPYTHONPATH

Python, Jython et IronPython lisent des emplacements supplémentaires à ajouter au
chemin de recherche de module à partir des variables
d’environnement PYTHONPATH , JYTHONPATH et IRONPYTHONPATH, respectivement. Si
vous souhaitez spécifier plusieurs emplacements dans l'un d'entre eux, vous devez
séparer les emplacements par deux-points sur les machines UNIX (par
exemple/opt/libs:$HOME/testlibs) et par un point-virgule sous Windows (par
exemple D:\libs;%HOMEPATH%\testlibs).

Les variables d'environnement peuvent être configurées de manière permanente sur

l'ensemble du système ou de manière à ne toucher qu'un certain utilisateur. Ils
peuvent également être définis temporairement avant d'exécuter une commande, ce
qui fonctionne très bien dans les scripts de démarrage personnalisés .

Remarque

Avant Robot Framework 2.9, le contenu de la variable d'environnement PYTHONPATH était

ajouté au chemin de recherche du module par le framework lui-même lors de l'exécution sur
Jython et IronPython. De nos jours, cela n'est plus fait
et JYTHONPATH et IRONPYTHONPATH doivent être utilisés avec ces interprètes.

En utilisant l' --pythonpathoption

Robot Framework a une option de ligne de commande séparée --pythonpath
(-P) pour ajouter des emplacements au chemin de recherche du module. Bien que
le nom de l'option contienne le mot Python, cela fonctionne également sur Jython et
IronPython.

Plusieurs emplacements peuvent être donnés en les séparant par un signe deux-
points, quel que soit le système d'exploitation, ou en utilisant cette option plusieurs
fois. Le chemin donné peut également être un motif de globalisation correspondant
à plusieurs chemins, mais il doit généralement être échappé .

Exemples:
--pythonpath libs
 --pythonpath /opt/testlibs:mylibs.zip:yourlibs
--pythonpath mylib.jar --pythonpath lib / STAR.jar --escape star: STAR

Configuration par sys.pathprogrammation

Les interpréteurs Python stockent le chemin de recherche de module qu'ils utilisent
comme liste de chaînes dans l' attribut sys.path . Cette liste peut être mise à jour
dynamiquement pendant l'exécution et les modifications sont prises en compte la
prochaine fois que quelque chose est importé.

Java classpath
Lorsque les bibliothèques implémentées en Java sont importées avec Jython, elles
peuvent se trouver soit dans le chemin de recherche de module normal de Jython,
soit dans classpath Java . La manière la plus courante de modifier le chemin d'accès
aux classes est de définir la variable d' environnement CLASSPATH de la même
manière que PYTHONPATH , JYTHONPATH ou IRONPYTHONPATH . Il est également possible
d'utiliser l' option de ligne de commande -cp de Java . Cette option n'est pas
exposée au script runner du robot , mais il est possible de l'utiliser avec Jython en
ajoutant le préfixe -J comme .jython -J-cp example.jar -m robot.run
tests.robot

Lorsque vous utilisez la distribution JAR autonome, le chemin de classe doit être
défini un peu différemment, car cette java -jarcommande prend en charge
la variable d' environnement CLASSPATHet l' option -cp . Il existe deux manières
différentes de configurer le chemin de classe:
java -cp lib / testlibrary.jar: lib / app.jar: robotframework-2.9.jar
org.robotframework.RobotFramework tests.robot
java -Xbootclasspath / a: lib / testlibrary.jar: lib / app.jar -jar
robotframework-2.9.jar tests.robot

3.4.6 Définition des variables

Les variables peuvent être définies à partir de la ligne de commande,
soit individuellement à l'aide de l' option --variable (-v) , soit via des
fichiers de variables avec l' option --variablefile (-V) . Les variables et
les fichiers de variables sont expliqués dans des chapitres distincts, mais les
exemples suivants illustrent comment utiliser ces options:
- nom variable: valeur
--Variable: Linux --Variable IP: 10.0.0.42
--variablefile path / to / variables.py
--variablefile myvars.py:possible:arguments:here
--variable ENVIRONMENT: Windows --variablefile c: \ resources \
windows.py

3.4.7 Course à sec

Robot Framework prend en charge ce que l'on appelle le mode de fonctionnement à
sec où les tests sont exécutés normalement autrement, mais les mots-clés provenant
des bibliothèques de tests ne sont pas exécutés du tout. Le mode de fonctionnement
à sec peut être utilisé pour valider les données de test; Si le passage à sec passe, les
données doivent être syntaxiquement correctes. Ce mode est déclenché en utilisant
l'option --dryrun .

L'exécution en exécution sèche peut échouer pour les raisons suivantes:

 Utilisation de mots clés introuvables.

 Utilisation de mots-clés avec un nombre d'arguments incorrect.
 Utilisation de mots-clés utilisateur dont la syntaxe est incorrecte.

En plus de ces échecs, les erreurs d'exécution normales sont affichées, par exemple,
lorsque les importations de la bibliothèque de tests ou des fichiers de ressources ne
peuvent pas être résolues.

Il est possible de désactiver la validation par analyse à sec des mots-clés

utilisateur spécifiques en leur ajoutant un robot:no-dry-run mot-clé spécial . Ceci est
utile si un mot-clé échoue en mode de fonctionnement à sec pour une raison
quelconque, mais fonctionne correctement lorsqu'il est exécuté
normalement. Désactiver le fonctionnement à sec est une nouvelle fonctionnalité de
Robot Framework 3.0.2.

Remarque

Le mode de fonctionnement à sec ne valide pas les variables.

3.4.8 Ordre d'exécution aléatoire

L'ordre d'exécution du test peut être randomisé en utilisant l'option --randomize
<what> [: <seed>] , où se <what>trouve l'un des éléments suivants:
tests
Les cas de test dans chaque suite de tests sont exécutés dans un ordre
aléatoire.
suites
Toutes les suites de tests sont exécutées dans un ordre aléatoire, mais les
scénarios de test dans les suites sont exécutés dans l'ordre dans lequel ils sont
définis.
all
Les scénarios de test et les suites de tests sont exécutés dans un ordre
aléatoire.
none
 Ni l'ordre d'exécution du test ni les suites ne sont randomisés. Cette valeur
peut être utilisée pour remplacer la valeur précédente définie avec --
randomize .

À partir de Robot Framework 2.8.5, il est possible de donner une graine

personnalisée pour initialiser le générateur aléatoire. Ceci est utile si vous souhaitez
réexécuter des tests en utilisant le même ordre que précédemment. La graine fait
partie de la valeur de --randomize in format <what>:<seed>et doit être un
entier. Si aucune graine n'est donnée, elle est générée aléatoirement. La suite de
tests de niveau supérieur exécutée obtient automatiquement
les métadonnées nommées Randomized qui indiquent à la fois ce qui a été aléatoire
et quelle graine a été utilisée.

Exemples:
robot - tests de randomisation my_test.robot
robot - tous les codes: 12345 path / to / tests

3.4.9 Modification programmatique des données de test

Si les fonctionnalités intégrées fournies pour modifier les données de test avant leur
exécution ne sont pas suffisantes, Robot Framework 2.9 et versions ultérieures
permettent d'effectuer des modifications personnalisées par programme. Pour ce
faire, vous devez créer un modificateur pré-exécution et l'activer à l'aide de
l' option --prerunmodifier .

Les modificateurs pré-exécution doivent être implémentés en tant que visiteurs

pouvant traverser la structure de la suite de tests exécutable et les modifier si
nécessaire. L'interface visiteur est expliquée dans le cadre de la documentation de
l'API Robot Framework , et il est possible de modifier les suites de tests , les cas de test et
les mots - clés exécutés à l' aide de celle-ci. Les exemples ci-dessous devraient
donner une idée de la manière dont les modificateurs pré-exécution peuvent être
utilisés et de la puissance de cette fonctionnalité.

Lorsqu'un modificateur de pré-exécution est utilisé sur la ligne de commande à

l'aide de l' option --prerunmodifier , il peut être spécifié soit comme nom de
la classe de modificateur, soit comme chemin d'accès au fichier de modificateur. Si
le modificateur est donné sous la forme d'un nom de classe, le module contenant la
classe doit se trouver dans le chemin de recherche du module et si le nom du module
est différent du nom de la classe, le nom doit inclure les
deux module.ModifierClass. Si le modificateur est donné sous la forme d'un
chemin, le nom de la classe doit être identique au nom du fichier. Pour la plupart
des pièces, cela fonctionne exactement comme lors de l' importation d'une bibliothèque
de tests .
Si un modificateur nécessite des arguments, comme le font les exemples ci-
dessous, ils peuvent être spécifiés après le nom ou le chemin du modificateur en
utilisant un signe deux-points ( :) ou un point-virgule ( ;) comme séparateur. Si les
deux sont utilisés dans la valeur, le premier est considéré comme le séparateur réel.

Si plusieurs modificateurs de pré-exécution sont nécessaires, ils peuvent être

spécifiés à l'aide de l' option --prerunmodifier plusieurs fois. Si des
modifications similaires sont nécessaires avant de créer des journaux et des
rapports, la modification programmatique des résultats peut être activée à l'aide de
l' option --prerebotmodifier .

Exemple: sélectionnez tous les X tests

Le premier exemple montre comment un modificateur de pré-exécution peut
supprimer des tests de la structure de la suite de tests exécutée. Dans cet exemple,
seuls les X tests sont conservés, et le X est fourni à partir de la ligne de commande
avec un index de démarrage facultatif.
"" "Modificateur de pré-exécution qui ne sélectionne que tous les X tests
pour exécution.

Commence par le premier test par défaut. Les tests sont sélectionnés par
suite.
"" "

à partir de robot.api import SuiteVisitor

classe SelectEveryXthTest ( SuiteVisitor ):

def __init__ ( self , x , start = 0 ):

self . x = int ( x )
self . start = int ( start )

def start_suite ( auto , la suite ):

"" "Modifier les essais de suite pour ne contenir que tous les
Xème." "" la
suite . essais = Suite . tests [ self . commencer :: auto . x ]

def end_suite ( self , suite ):

"" Supprimez les suites vides après la suppression des tests. "" "
suite . suites = [ s pour s en suite . suites si s .
test_count > 0 ]

def visit_test ( self , test ):

"" Evitez les tests de visite et leurs mots clés pour gagner un peu
de temps. "" "
pass

Si le modificateur de pré-exécution ci-dessus se trouve dans un

fichier SelectEveryXthTest.py et que le fichier se trouve dans le chemin de
recherche du module , il pourrait être utilisé comme ceci:
 # Spécifiez le modificateur comme chemin. Exécutez chaque deuxième
test.
robot --prununmodifier path / to / SelectEveryXthTest.py: 2
tests.robot

# Spécifiez le modificateur comme nom. Exécutez chaque troisième test,

en commençant par le second.
robot --prununmodifier SelectEveryXthTest: 3: 1 tests.robot

Exemple: Exclure les tests par nom

Le deuxième exemple supprime également les tests, cette fois en fonction d'un
modèle de nom donné. En pratique, cela fonctionne comme une version négative de
l' option --test intégrée .
"" "Modificateur de pré-exécution qui exclut les tests par leur nom.

Les tests à exclure sont spécifiés en utilisant un modèle qui est

insensible
à la casse et à l'espace et qui prend en charge '*' (correspond à tout) et
'?' (correspond à un seul caractère) en tant que joker.
"" "

de robot.api importation SuiteVisitor

de robot.utils importer Matcher

classe ExcludeTests ( SuiteVisitor ):

def __init__ ( self , pattern ):

self . matcher = Matcher ( pattern )

defstart_suite ( self , suite ):

"" Supprimer les tests correspondant au modèle donné. "" "
suite . tests = [ t pour t en suite . des tests si pas
auto . _is_excluded ( t )]

def_is_excluded ( self , test ):

retourne moi-même . matcher . match ( test . name ) ou self .
matcher . match ( test . longname )

defend_suite ( self , suite ):

"" Supprimez les suites vides après la suppression des tests. "" "
suite . suites = [ s pour s en suite . suites si s .
test_count > 0 ]

defvisit_test ( self , test ):

"" Evitez les tests de visite et leurs mots clés pour gagner un peu
de temps. "" "
pass

En supposant que le modificateur ci-dessus se trouve dans un fichier

nommé ExcludeTests.py , il pourrait être utilisé comme ceci:
# Exclure le test nommé "Exemple".
robot --prununmodifier path / to / ExcludeTests.py: Exemple
tests.robot
 # Exclure tous les tests se terminant par «quelque chose».
robot --prununmodifier path / to / ExcludeTests.py: * quelque chose
tests.robot

Exemple: Ignorer les configurations et les démontages

Parfois, lors des tests de débogage, il peut être utile de désactiver les configurations
ou les démontages. Ceci peut être accompli en éditant les données de test, mais les
modificateurs pré-exécutables facilitent cette opération pour une seule exécution:
"" Modificateurs pré-exécutables pour désactiver les configurations et les
démontages de la suite et des tests. "" "

à partir de robot.api import SuiteVisitor

classe SuiteSetup ( SuiteVisitor ):

def start_suite ( self , suite ):

suite . mots - clés . setup = Aucun

classe SuiteTeardown ( SuiteVisitor ):

def start_suite ( self , suite ):

suite . mots - clés . démontage = Aucun

classe TestSetup ( SuiteVisitor ):

def start_test ( self , test ):

test . mots - clés . setup = Aucun

classe TestTeardown ( SuiteVisitor ):

def start_test ( self , test ):

test . mots - clés . démontage = Aucun

En supposant que les modificateurs ci-dessus se trouvent tous dans un fichier

nommé disable.py et que ce fichier se trouve dans le chemin de recherche du module ,
les configurations et les démontages peuvent être désactivés, par exemple, comme
suit:
# Désactiver les démontages de suites.
robot --prununmodifier disable.SuiteTeardown tests.robot

# Désactivez à la fois les configurations de test et les démontages à

l'aide de l'option '--prununmodifier' deux fois.
robot --prununmodifier disable.TestSetup --prerunmodifier
disable.TestTeardown tests.robot

3.4.10 Contrôle de la sortie de la console

Il existe différentes options de ligne de commande pour contrôler la manière dont
l'exécution du test est signalée sur la console.

Type de sortie de la console

Le type de sortie global de la console est défini avec l' option --console . Il
prend en charge les valeurs insensibles à la casse suivantes:
verbose
Chaque suite de tests et cas de test est signalé individuellement. Ceci est la
valeur par défaut.
dotted
Afficher uniquement .pour le test réussi, fpour les tests non critiques
ayant F échoué , pour les tests critiques ayant échoué et xpour les tests
ignorés à la suite de l' exécution du test . Les tests critiques ayant échoué sont
répertoriés séparément après exécution. Ce type de sortie permet de voir
facilement s'il y a des défaillances pendant l'exécution même s'il y aurait
beaucoup de tests.
quiet
Aucune sortie sauf pour les erreurs et les avertissements .
none
Aucune sortie que ce soit. Utile lors de la création d'une sortie personnalisée
à l'aide, par exemple, d' écouteurs .

Des options de commodité séparées --dotted (-.) Et --quiet sont des

raccourcis pour --console dottedet --console quiet, respectivement.

Exemples:
robot --console calme tests.robot
robot --dotted tests.robot

Remarque

--console , --dotted et --quiet sont de nouvelles options dans Robot Framework

2.9. Avant cela, la sortie était toujours la même que dans le verbosemode actuel .

Largeur de la console
La largeur de la sortie d'exécution du test dans la console peut être définie à l'aide
de l'option --consolewidth (-W) . La largeur par défaut est de 78 caractères.

Pointe

Sur de nombreuses machines de type UNIX, vous pouvez utiliser $COLUMNS une variable
d'environnement pratique comme --consolewidth $COLUMNS.
Remarque

Avant Robot Framework 2.9, cette fonctionnalité était activée avec l' option --
monitorwidth qui était la première fois obsolète et qui est aujourd'hui supprimée. L'option
courte -W fonctionne de la même manière dans toutes les versions.

Couleurs de la console
L' option --consolecolors (-C) permet de contrôler si les couleurs
doivent être utilisées dans la sortie de la console. Les couleurs sont implémentées à
l'aide des couleurs ANSI sauf sous Windows où, par défaut, les API Windows sont
utilisées à la place. L'accès à ces API à partir de Jython n'est pas possible et, par
conséquent, les couleurs ne fonctionnent pas avec Jython sous Windows.

Cette option prend en charge les valeurs insensibles à la casse suivantes:

auto
Les couleurs sont activées lorsque les sorties sont écrites dans la console,
mais pas lorsqu'elles sont redirigées dans un fichier ou ailleurs. Ceci est la
valeur par défaut.
on
Les couleurs sont également utilisées lorsque les sorties sont redirigées. Ne
fonctionne pas sous Windows.
ansi
Identique onmais utilise les couleurs ANSI également sous Windows. Utile,
par exemple, lorsque vous redirigez la sortie vers un programme qui
comprend les couleurs ANSI. Nouveau dans Robot Framework 2.7.5.
off
Les couleurs sont désactivées.

Remarque

Avant Robot Framework 2.9, cette fonctionnalité était activée avec l' option --
monitorcolors qui était la première fois obsolète et qui est aujourd'hui
supprimée. L'option courte -C fonctionne de la même manière dans toutes les versions.

Marqueurs de console
À partir de Robot Framework 2.7, des marqueurs spéciaux .(succès) et F(échec)
sont affichés sur la console lors de l'utilisation de la sortie détaillée et des mots clés
de niveau supérieur à la fin des tests élémentaires. Les marqueurs permettent de
suivre l'exécution du test en haut niveau et ils sont effacés à la fin des tests.
À partir de Robot Framework 2.7.4, il est possible de configurer le moment où les
marqueurs sont utilisés avec l' option --consolemarkers (-K) . Il prend
en charge les valeurs insensibles à la casse suivantes:
auto
Les marqueurs sont activés lorsque la sortie standard est écrite dans la
console, mais pas lorsqu'elle est redirigée dans un fichier ou ailleurs. Ceci est
la valeur par défaut.
on
Les marqueurs sont toujours utilisés.
off
Les marqueurs sont désactivés.

Remarque

Avant Robot Framework 2.9, cette fonctionnalité était activée avec l' option --
monitormarkers qui était la première fois obsolète et qui est aujourd'hui
supprimée. L'option courte -K fonctionne de la même manière dans toutes les versions.

3.4.11 Réglage des écouteurs

Les auditeurs peuvent être utilisés pour surveiller l'exécution du test. Lorsqu'ils sont
utilisés depuis la ligne de commande, ils sont spécifiés à l'aide de l' option de ligne
de commande --listener . La valeur peut être un chemin d'accès à un écouteur
ou à un nom d'écouteur. Reportez-vous à la section Interface de l' écouteur pour plus
d'informations sur l'importation des écouteurs et leur utilisation en général.

3.5 sorties créées

Plusieurs fichiers de sortie sont créés lors de l'exécution des tests et tous sont liés
d'une manière ou d'une autre aux résultats des tests. Cette section présente les
sorties créées, la configuration de leur création et la mise au point de leur contenu.

 3.5.1 Différents fichiers de sortie

o Répertoire de sortie
o Fichier de sortie
o Fichier journal
o Fichier de rapport
o Fichier de résultat compatible XUnit
o Fichier de débogage
o Fichiers de sortie d'horodatage
o Définition des titres
o Définition des couleurs d'arrière-plan
 3.5.2 Niveaux de journalisation
o Niveaux de journal disponibles
o Définition du niveau de journalisation
 o Niveau de journal visible
 3.5.3 Fractionnement des journaux
 3.5.4 Configuration des statistiques
o Configuration des statistiques de suite affichées
o Y compris et exclure les statistiques de tag
o Génération de statistiques de balises combinées
o Création de liens à partir de noms de balises
o Ajouter de la documentation aux balises
 3.5.5 Supprimer et aplatir les mots-clés
o Supprimer des mots-clés
o Mots-clés d'aplatissement
 3.5.6 Réglage de l'heure de début et de fin de l'exécution
 3.5.7 Modification programmatique des résultats
 3.5.8 Journal du système

3.5.1 Différents fichiers de sortie

Cette section explique quels différents fichiers de sortie peuvent être créés et
comment les configurer. Les fichiers de sortie sont configurés à l'aide des options
de ligne de commande, qui permettent d'obtenir le chemin d'accès au fichier de
sortie en question. Une valeur spéciale NONE (insensible à la casse) peut être utilisée
pour désactiver la création d'un fichier de sortie spécifique .

Répertoire de sortie
Tous les fichiers de sortie peuvent être définis à l'aide d'un chemin absolu, auquel
cas ils sont créés à l'emplacement spécifié, mais dans d'autres cas, le chemin est
considéré par rapport au répertoire de sortie. Le répertoire de sortie par défaut est le
répertoire à partir duquel l'exécution est lancée, mais il peut être modifié avec
l' option --outputdir (-d) . Le chemin défini avec cette option est, encore
une fois, relatif au répertoire d'exécution, mais peut naturellement être donné
également comme chemin absolu. Indépendamment de la manière dont le chemin
d'accès à un fichier de sortie individuel est obtenu, son répertoire parent est créé
automatiquement, s'il n'existe pas déjà.

Fichier de sortie
Les fichiers de sortie contiennent tous les résultats de l'exécution du test au format
XML lisible par machine. Les fichiers journaux , les rapports et les fichiers xUnit sont
généralement générés en fonction de ces fichiers. Ils peuvent également être
combinés et traités ultérieurement avec Rebot .

Pointe

À partir de Robot Framework 2.8, la génération de fichiers de rapports et de xUnit dans le

cadre de l'exécution de tests ne nécessite plus le traitement des fichiers de sortie. La
désactivation de la génération de journaux lors de l'exécution de tests peut donc économiser
de la mémoire.

L'option de ligne de commande --output (-o) détermine le chemin où le

fichier de sortie est créé par rapport au répertoire de sortie . Le nom par défaut du
fichier de sortie, lors de l'exécution des tests, est output.xml .

Lors du post-traitement des sorties avec Rebot, les nouveaux fichiers de sortie ne sont
créés que si l' option --output est explicitement utilisée.

Il est possible de désactiver la création du fichier de sortie lors de l'exécution des

tests en attribuant une valeur spéciale NONEà l' option --output . Avant Robot
Framework 2.8, cela désactivait automatiquement la création de fichiers journaux et
de rapports, mais cela n'est plus le cas actuellement. Si aucune sortie n'est
nécessaire, elles doivent toutes être explicitement désactivées à l'aide de --output
NONE --report NONE --log NONE.

Fichier journal
Les fichiers journaux contiennent des détails sur les scénarios de test exécutés au
format HTML. Ils ont une structure hiérarchique montrant la suite de tests, les cas
de test et les détails des mots clés. Les fichiers journaux sont nécessaires presque
chaque fois que les résultats des tests doivent être examinés en détail. Même si les
fichiers journaux contiennent également des statistiques, les rapports sont plus
adaptés pour obtenir une vue d'ensemble de niveau supérieur.

L'option de ligne de commande --log (-l) détermine où les fichiers journaux

sont créés. Sauf si la valeur spéciale NONEest utilisée, les fichiers journaux sont
toujours créés et leur nom par défaut estlog.html .
Un exemple de début d'un fichier journal

Un exemple de fichier journal avec les détails des mots clés visibles

Fichier de rapport
Les fichiers de rapport contiennent une vue d'ensemble des résultats de l'exécution
du test au format HTML. Ils ont des statistiques basées sur des balises et des suites
de tests exécutées, ainsi qu'une liste de tous les cas de test exécutés. Lorsque les
rapports et les journaux sont générés, le rapport contient des liens vers le fichier
journal pour faciliter la navigation vers des informations plus détaillées. Il est facile
de voir l'état d'exécution du test global à partir du rapport, car sa couleur d'arrière-
plan est verte, si tous les tests critiques sont réussis, et rouge vif dans le cas contraire.

L'option de ligne de commande --report (-r) détermine où les fichiers de

rapport sont créés. De la même manière que les fichiers journaux, les rapports sont
toujours créés, sauf s'ils NONEsont utilisés comme valeur et que leur nom par défaut
est report.html .

Un exemple de fichier de rapport sur l'exécution réussie d'un test

Un exemple de fichier de rapport ayant échoué à l'exécution du test

Fichier de résultat compatible XUnit

Les fichiers de résultats XUnit contiennent le résumé de l'exécution des tests
au format XML compatible avec xUnit . Ces fichiers peuvent donc être utilisés
comme entrée pour des outils externes qui comprennent les rapports xUnit. Par
exemple, le serveur d'intégration continue de Jenkins prend en charge la génération
de statistiques basées sur des résultats compatibles avec xUnit.

Pointe

Jenkins a également un plugin séparé pour Robot Framework .

Les fichiers de sortie XUnit ne sont créés que si l'option de ligne de commande --
xunit (-x) est utilisée de manière explicite. Cette option nécessite un chemin
d'accès au fichier xUnit généré, relatif au répertoire de sortie , en tant que valeur.

Étant donné que les rapports xUnit n'ont pas le concept de tests non critiques , tous
les tests d'un rapport xUnit seront marqués comme ayant réussi ou échoué, sans
distinction entre les tests critiques et non critiques. Si cela pose problème,
l' option --xunitskipnoncritical peut être utilisée pour marquer les tests
non critiques comme étant ignorés. Les tests ignorés recevront un message
contenant le statut réel et le message possible du test élémentaire dans un format
similaire FAIL: Error message.

Remarque

--xunitskipnoncritical est une nouvelle option de Robot Framework 2.8.

Fichier de débogage
Les fichiers de débogage sont des fichiers texte simples écrits lors de l'exécution du
test. Tous les messages provenant des bibliothèques de tests leur sont écrits, ainsi
que des informations sur les suites de tests, les cas de test et les mots-clés démarrés
et terminés. Les fichiers de débogage peuvent être utilisés pour surveiller
l'exécution du test. Cela peut être fait en utilisant, par exemple,
un outil séparé fileviewer.py , ou dans des systèmes UNIX, simplement avec
la commande tail -f .

Les fichiers de débogage ne sont créés que si l'option de ligne de commande --

debugfile (-b) est utilisée explicitement.

Fichiers de sortie d'horodatage

Tous les fichiers de sortie répertoriés dans cette section peuvent être
automatiquement horodatés avec l'option --timestampoutputs (-
T) . Lorsque cette option est utilisée, un horodatage dans le format YYYYMMDD-
hhmmssest placé entre l'extension et le nom de base de chaque fichier. L'exemple ci-
dessous, par exemple, créerait des fichiers de sortie tels que output-20080604-
163225.xml et mylog-20080604-163225.html :
robot --timestampoutputs --log mylog.html --report NONE tests.robot

Définition des titres

Les titres par défaut des journaux et des rapports sont générés en préfixant le nom de
la suite de tests de niveau supérieur avec le journal de test ou le rapport de
test . Des titres personnalisés peuvent être donnés à partir de la ligne de commande
en utilisant les options --logtitle et --reporttitle , respectivement. Les
traits de soulignement dans les titres donnés sont automatiquement convertis en
espaces.

Exemple:
robot --logtitle Smoke_Test_Log --reporttitle Smoke_Test_Report --
include fumée my_tests /

Définition des couleurs d'arrière-plan

Par défaut, le fichier de rapport a un arrière-plan vert lorsque tous les tests
critiques réussissent et un arrière-plan rouge sinon. Ces couleurs peuvent être
personnalisées à l'aide de l' option de ligne de commande --
reportbackground , qui prend deux ou trois couleurs séparées par
un signe deux-points:
 --reportbackground blue: red
--reportbackground vert: jaune: rouge
--reportbackground # 00F: # E00

Si vous spécifiez deux couleurs, la première sera utilisée à la place de la couleur

verte par défaut et la seconde au lieu du rouge par défaut. Cela permet, par
exemple, d'utiliser du bleu au lieu du vert pour faciliter la séparation des arrière-
plans pour les personnes daltoniennes.

Si vous spécifiez trois couleurs, la première sera utilisée lorsque tout le test
réussira, la seconde lorsque seuls les tests non critiques auront échoué et la dernière
en cas de défaillance critique. Cette fonctionnalité permet donc d’utiliser une
couleur de fond distincte, par exemple jaune, lorsque les tests non critiques ont
échoué.

Les couleurs spécifiées sont utilisées comme valeur pour la propriété CSS
de l' body élément background. La valeur est utilisée telle quelle et peut être un nom
de couleur HTML (par exemple red), une valeur hexadécimale (par
exemple #f00ou #ff0000) ou une valeur RVB (par exemple rgb(255,0,0)). Les
couleurs vert et rouge par défaut sont spécifiées à l'aide de valeurs
hexadécimales #9e9et #f66, respectivement.

3.5.2 Niveaux de journalisation

Niveaux de journal disponibles
Les messages dans les fichiers journaux peuvent avoir des niveaux de journal
différents. Certains messages sont écrits par Robot Framework lui-même, mais les
mots clés exécutés peuvent également consigner des informations à différents
niveaux. Les niveaux de journalisation disponibles sont les suivants:
FAIL
Utilisé lorsqu'un mot clé échoue. Peut être utilisé que par Robot Framework
lui-même.
WARN
Utilisé pour afficher les avertissements. Ils apparaissent également dans la
console et dans la section Erreurs d’exécution de test dans les fichiers journaux , mais
ils n’affectent pas le statut du scénario de test.
INFO
Le niveau par défaut pour les messages normaux. Par défaut, les messages
inférieurs à ce niveau ne sont pas affichés dans le fichier journal.
DEBUG
Utilisé à des fins de débogage. Utile, par exemple, pour consigner ce que les
bibliothèques font en interne. Lorsqu'un mot clé échoue, une trace indiquant
 où dans le code l'échec s'est produit est consignée automatiquement avec ce
niveau.
TRACE
Niveau de débogage plus détaillé. Les arguments de mot-clé et les valeurs de
retour sont automatiquement consignés à ce niveau.

Définition du niveau de journalisation

Par défaut, les messages de journal inférieurs au INFOniveau ne sont pas consignés,
mais ce seuil peut être modifié à partir de la ligne de commande à l'aide de
l' option --loglevel (-L) . Cette option prend en charge n'importe quel
niveau de journal disponible et ce niveau devient le nouveau niveau de seuil. Une
valeur spéciale NONEpeut également être utilisée pour désactiver la journalisation.

Il est possible d'utiliser l' option --loglevel également lors du post-traitement des
sorties avec Rebot. Cela permet, par exemple, d'exécuter initialement des tests avec
le TRACEniveau et de générer des fichiers journaux plus petits pour une visualisation
normale ultérieure avec le INFOniveau. Par défaut, tous les messages inclus lors de
l'exécution seront également inclus avec Rebot. Les messages ignorés lors de
l'exécution ne peuvent pas être récupérés.

Une autre possibilité de modifier le niveau de consignation consiste à utiliser le mot-

clé BuiltIn Set Log Level dans les données de test. Il prend les mêmes arguments que
l' option --loglevel et renvoie l'ancien niveau afin qu'il puisse être restauré
ultérieurement, par exemple lors d'un test de démontage .

Niveau de journal visible

À partir de Robot Framework 2.7.2, si le fichier journal contient des messages
à DEBUGou TRACEniveaux, une liste déroulante de niveau de journal visible est
affichée dans le coin supérieur droit. Cela permet aux utilisateurs de supprimer les
messages sous le niveau choisi de la vue. Cela peut être utile en particulier lors des
tests de TRACEniveau.
Un exemple de journal indiquant la liste déroulante du niveau de journal visible

Par défaut, le menu déroulant sera défini au niveau le plus bas du fichier journal,
afin que tous les messages soient affichés. Le niveau de journalisation visible par
défaut peut être modifié à l'aide de l' option --loglevel en attribuant la valeur
par défaut après le niveau de journalisation normal séparé par deux points:
--loglevel DEBUG: INFO

Dans l'exemple ci-dessus, les tests sont exécutés à l'aide de level DEBUG, mais le
niveau visible par défaut dans le fichier journal est INFO.

3.5.3 Fractionnement des journaux

Normalement, le fichier journal est juste un fichier HTML unique. Lorsque la
quantité de cas de test augmente, la taille du fichier peut devenir si importante que
son ouverture dans un navigateur est peu pratique, voire impossible. Par
conséquent, il est possible d'utiliser l' option --splitlog pour séparer des
parties du journal en fichiers externes chargés en toute transparence dans le
navigateur, si nécessaire.

Le principal avantage de la division des journaux est que les parties de journal
individuelles sont si petites que l'ouverture et la navigation dans le fichier journal
sont possibles même si la quantité de données de test est très importante. Un petit
inconvénient est que la taille globale prise par le fichier journal augmente.

Techniquement, les données de test relatives à chaque test élémentaire sont

enregistrées dans un fichier JavaScript dans le même dossier que le fichier journal
principal. Ces fichiers ont des noms tels que log-42.js où log est le nom de base du
fichier journal principal et 42 est un index incrémenté.

Remarque

Lors de la copie des fichiers journaux, vous devez également copier tous les fichiers log - *.
Js ou certaines informations seront manquantes.

3.5.4 Configuration des statistiques

Plusieurs options de ligne de commande peuvent être utilisées pour configurer et
ajuster le contenu des tables Statistics by Tag , Statistics by Suite et Test Details by
Tag dans différents fichiers de sortie. Toutes ces options fonctionnent à la fois lors
de l'exécution de scénarios de test et lors du post-traitement des sorties.

Configuration des statistiques de suite affichées

Lorsqu'une structure de suite plus profonde est exécutée, l'affichage de tous les
niveaux de la suite de tests dans la table Statistics by Suite peut compliquer la
lecture du tableau. Par défaut, toutes les suites sont affichées, mais vous pouvez
contrôler cela avec l'option de ligne de commande --suitestatlevel qui
prend le niveau des suites à afficher comme argument:
--suitestatlevel 3

Y compris et exclure les statistiques de tag

Lorsque plusieurs balises sont utilisées, la table Statistics by Tag peut devenir très
encombrée. Si cela se produit, les options de ligne de commande --
tagstatinclude et --tagstatexclude peuvent être utilisées pour
sélectionner les balises à afficher, de la même manière que --include et --
exclude pour sélectionner des scénarios de test :
--tagstatinclude some-tag --tagstatinclude another-tag
--tagstatexclude owner- *
--tagstatinclude prefix- * --tagstatexclude prefix-13

Génération de statistiques de balises combinées

L'option de ligne de commande --tagstatcombine peut être utilisée pour
générer des balises agrégées combinant des statistiques provenant de plusieurs
balises. Les balises combinées sont spécifiées à l'aide de modèles de
balises où *et ?sont prises en charge en tant que caractères génériques et AND, ORet
les NOTopérateurs peuvent être utilisés pour combiner des balises ou des motifs
individuels.
Les exemples suivants illustrent la création de statistiques de balises combinées à
l'aide de différents modèles. La figure ci-dessous montre un extrait
du tableau Statistiques par balise résultant :
--tagstatcombine owner- *
--tagstatcombine smokeANDmytag
--tagstatcombine smokeNOTowner-janne *

Exemples de statistiques de balises combinées

Comme l'illustre l'exemple ci-dessus, le nom de la statistique combinée ajoutée est,

par défaut, uniquement le modèle donné. Si cela ne suffit pas, il est possible de
donner un nom personnalisé après le modèle en les séparant par un deux-points
( :). Les traits de soulignement possibles dans le nom sont convertis en espaces:
--tagstatcombine prio1ORprio2: High_priority_tests

Création de liens à partir de noms de balises

Vous pouvez ajouter des liens externes à la table Statistics by Tag en utilisant
l'option de ligne de commande --tagstatlink . Les arguments pour cette
option sont donnés dans le format tag:link:name, où tag spécifie les balises
auxquelles attribuer le lien, linkest le lien à créer et nameest le nom à donner au
lien.

tagpeut être une simple étiquette, mais le plus souvent un simple

motif où *tout ?correspond à n'importe quel caractère. Quand tagest un modèle, les
correspondances avec les caractères génériques peuvent être utilisées
dans linket titleavec la syntaxe %N, où "N" est l'index de la correspondance à
partir de 1.

Les exemples suivants illustrent l'utilisation de cette option et la figure ci-dessous

illustre un extrait de la table Statistics by Tag obtenue lorsque des exemples de
données de test sont exécutés avec ces options:
--tagstatlink mytag: http: //www.google.com: Google
--tagstatlink jython-bug- *: http: //bugs.jython.org/issue_%1: Jython-
bugs
--tagstatlink owner - *: mailto: %1@domain.com? subject =
Acceptance_Tests: Send_Mail

Exemples de liens à partir de noms de tags

Ajouter de la documentation aux balises
Les balises peuvent recevoir une documentation avec l'option de ligne de
commande --tagdoc , qui prend un argument au format tag:doc. tagest le nom
de la balise à laquelle attribuer la documentation, et il peut également s'agir
d'un simple motif correspondant à plusieurs balises. docest la documentation
attribuée. Les caractères de soulignement dans la documentation sont
automatiquement convertis en espaces et peuvent également contenir une mise en
forme HTML .

La documentation donnée est affichée avec des balises correspondantes dans

la table Test Details by Tag et comme une info-bulle pour ces balises dans
la table Statistics by Tag . Si une balise reçoit plusieurs documentations, elles sont
combinées et séparées par une perluète.

Exemples:
--tagdoc mytag: My_documentation
--tagdoc regression: * Voir * _http: //info.html
--tagdoc owner - *: Original_author

3.5.5 Supprimer et aplatir les mots-clés

La plupart du contenu des fichiers de sortie provient des mots-clés et de leurs
messages de journal. Lors de la création de rapports de niveau supérieur, les
fichiers journaux ne sont pas nécessairement nécessaires et, dans ce cas, les mots-
clés et leurs messages prennent tout simplement de la place. Les fichiers journaux
eux-mêmes peuvent également devenir trop volumineux, surtout s'ils
contiennent des boucles ou d'autres constructions qui répètent plusieurs mots-clés à
plusieurs reprises.

Dans ces situations, les options de ligne de commande --removekeywords et -

-flattenkeywords peuvent être utilisées pour éliminer ou aplatir les mots-clés
inutiles. Ils peuvent être utilisés à la fois lors de l' exécution de scénarios de test et lors
du post-traitement des sorties . Lorsqu'ils sont utilisés lors de l'exécution, ils
n'affectent que le fichier journal, pas le fichier de sortie XML. Avec rebotelles
affectent les deux journaux et éventuellement de nouveaux fichiers XML de sortie.

Supprimer des mots-clés

L' option --removekeywords supprime complètement les mots-clés et leurs
messages. Il dispose des modes de fonctionnement suivants et peut être utilisé
plusieurs fois pour activer plusieurs modes. Les mots-clés contenant des erreurs ou
des avertissements ne sont pas supprimés, sauf lorsque vous utilisez le ALLmode.

ALL
 Supprimez les données de tous les mots clés sans condition.
PASSED
Supprimez les données de mot clé des cas de test réussis. Dans la plupart des
cas, les fichiers journaux créés à l'aide de cette option contiennent
suffisamment d'informations pour rechercher d'éventuelles défaillances.
FOR
Supprimez toutes les itérations passées pour les boucles for sauf la dernière.
WUKS
Supprimer tous les mots clés défaillants dans le mot-clé BuiltIn Attendre que
le mot-clé réussisse, à l'exception du dernier.
NAME:<pattern>
Supprimez les données de tous les mots-clés correspondant au modèle
donné, quel que soit le statut du mot-clé. Le modèle est mis en
correspondance avec le nom complet du mot-clé, préfixé par le nom de
fichier de bibliothèque ou de ressource possible. Le motif est insensible à la
casse, à l'espace et au trait de soulignement, et il prend en charge des motifs
simples avec * et ?comme caractères génériques.
TAG:<pattern>
Supprimez les données des mots-clés avec des balises correspondant au
modèle donné. Les tags sont le cas et dans l' espace insensible et ils peuvent
être spécifiées à l' aide des modèles d'étiquette où *et ?sont pris en charge
des caractères génériques et AND, ORet les NOT opérateurs peuvent être utilisés
pour combiner des étiquettes individuelles ou modèles ensemble. Peut être
utilisé avec des étiquettes de mots-clés de bibliothèque et des étiquettes de mots-clés
d' utilisateur .

Exemples:
rebot --removekeywords all --output removed.xml output.xml
robot --removekeywords transmis --removekeywords for tests.robot
robot --removekeywords name: HugeKeyword --removekeywords name:
ressource. * tests.robot
robot --removekeywords tag: énorme tests.robot

La suppression des mots-clés est effectuée après l'analyse du fichier de sortie et la

génération d'un modèle interne basé sur celui-ci. Ainsi, cela ne réduit pas
l’utilisation de la mémoire autant que l’ aplatissement des mots-clés .

Remarque

Le soutien à l' aide --removekeywords lors de l' exécution des tests, ainsi que FORet
les WUKSmodes ont été ajoutés dans le cadre Robot 2.7.

Remarque

NAME:<pattern>Le mode a été ajouté dans Robot Framework 2.8.2 et TAG:<pattern>dans

2.9.
Mots-clés d'aplatissement
L' option --flattenkeywords aplatit les mots clés correspondants. En
pratique, cela signifie que les mots-clés correspondants obtiennent tous les
messages de journalisation de leurs mots-clés enfants, récursivement, et que les
mots-clés enfants sont ignorés. L'aplatissement prend en charge les modes suivants:
FOR
Aplatir complètement les boucles .
FORITEM
Aplatir l'individu pour les itérations de boucle.
NAME:<pattern>
Aplatir les mots-clés correspondant au modèle donné. Les règles de
correspondance de modèle sont les mêmes que lors de la suppression de mots-
clés en NAME:<pattern>mode.
TAG:<pattern>
Aplatir les mots-clés avec des balises correspondant au modèle donné. Les
règles de correspondance de modèle sont les mêmes que lors de la suppression
de mots-clés en TAG:<pattern>mode.

Exemples:
robot --flattenkeywords name: HugeKeyword --flattenkeywords name:
ressource. * tests.robot
rebot --flattenkeywords foritem --output flattened.xml original.xml

L'aplatissement des mots-clés est déjà effectué lorsque le fichier de sortie est analysé
initialement. Cela permet d'économiser une quantité importante de mémoire, en
particulier avec des structures de mots clés profondément imbriquées.

Remarque

L'aplatissement des mots-clés est une nouvelle fonctionnalité de Robot Framework

2.8.2, FOR et les FORITEMmodes ont été ajoutés aux 2.8.5 et TAG:<pattern>2.9.

3.5.6 Réglage de l'heure de début et de fin de

l'exécution
Lorsque vous combinez des sorties à l' aide de Rebot, il est possible de définir l'heure
de début et de fin de la suite de tests combinée à l'aide des options --
starttime et --endtime , respectivement. Cela est pratique car, par défaut,
les suites combinées n'ont pas ces valeurs. Lorsque l'heure de début et l'heure de fin
sont indiquées, le temps écoulé est également calculé en fonction de ces
heures. Sinon, le temps écoulé est obtenu en ajoutant les temps écoulés des suites
de tests enfants.
Il est également possible d'utiliser les options mentionnées ci-dessus pour définir
les heures de début et de fin d'une seule suite lors de l'utilisation de
Rebot. L'utilisation de ces options avec une seule sortie affecte toujours le temps
écoulé de la suite.

Les temps doivent être donnés en tant qu'horodatages dans le format YYYY-MM-DD
hh:mm:ss.mil, où tous les séparateurs sont facultatifs et les parties allant de
millisecondes à heures peuvent être omises. Par exemple, 2008-06-11
17:59:20.495est équivalent à 20080611-175920.495et 20080611175920495, et aussi
simple 20080611fonctionnerait.

Exemples:
rebot --starttime 20080611-17: 59: 20.495 output1.xml output2.xml
rebot --starttime 20080611-175920 --endtime 20080611-180242 * .xml
rebot --starttime 20110302-1317 --endtime 20110302-11418 myoutput.xml

3.5.7 Modification programmatique des résultats

Si les fonctionnalités intégrées fournies pour modifier les résultats ne suffisent pas,
Robot Framework 2.9 et versions ultérieures permettent d'effectuer des
modifications personnalisées par programme. Ceci est accompli en créant un
modificateur de modèle et en l'activant en utilisant l' option --
prerebotmodifier .

Cette fonctionnalité fonctionne presque exactement comme la modification par

programmation de données de test pouvant être activées avec l' option --
prerunmodifier . La différence évidente est que cette fois les modificateurs
fonctionnent avec le modèle de résultat , pas le modèle en cours d'exécution . Par
exemple, les marques de modification suivantes ont toutes réussi les tests qui ont
pris plus de temps qu'autorisé car elles ont échoué:
à partir de robot.api import SuiteVisitor

classe ExecutionTimeChecker ( SuiteVisitor ):

def __init__ ( self , max_seconds ):

self . max_milliseconds = float ( max_seconds ) * 1000

def visit_test ( self , test ):

si test . status == 'PASS' et test . temps écoulé > auto .
max_milliseconds :
test . status = Test 'FAIL'
. message = 'L'exécution du test a pris trop de temps.'

Si le modificateur ci-dessus se trouvait dans le fichier ExecutionTimeChecker.py , il

pourrait être utilisé, par exemple, comme ceci:
 # Spécifiez le modificateur comme chemin lors de l'exécution des
tests. Le temps maximum est de 42 secondes.
robot --prerebotmodifier path / to / ExecutionTimeChecker.py: 42
tests.robot

# Spécifiez le modificateur comme nom lorsque vous utilisez Rebot. La

durée maximale est de 3,14 secondes.
# ExecutionTimeChecker.py doit figurer dans le chemin de recherche du
module.
rebot --prerebotmodifier ExecutionTimeChecker: 3.14 output.xml

Si plusieurs modificateurs de modèle sont nécessaires, ils peuvent être spécifiés à

l'aide de l' option --prerebotmodifier plusieurs fois. Lors de l'exécution des
tests, il est possible d'utiliser les options --prununmodifier et --
prerebotmodifier ensemble.

3.5.8 Journal du système

Robot Framework possède son propre journal système en texte brut où il écrit des
informations sur

 Fichiers de données de test traités et ignorés

 Bibliothèques de test, fichiers de ressources et fichiers variables
importés
 Suites de test et cas de test exécutés
 Sorties créées

Normalement, les utilisateurs n'ont jamais besoin de ces informations, mais cela
peut être utile lors de la recherche de problèmes avec les bibliothèques de tests ou
avec Robot Framework lui-même. Un journal système n'est pas créé par défaut,
mais il peut être activé en définissant la variable
d'environnement ROBOT_SYSLOG_FILE afin qu'il contienne un chemin d'accès au
fichier sélectionné.

Un journal système a les mêmes niveaux de journalisation qu'un fichier journal

normal, à l'exception qu'au lieu de FAILcela a le ERROR niveau. Le niveau de seuil à
utiliser peut être modifié à l'aide de la variable
d'environnement ROBOT_SYSLOG_LEVEL , comme indiqué dans l'exemple ci-
dessous. Des erreurs et des avertissements inattendus possibles sont écrits dans le
journal système en plus de la console et du fichier journal normal.
#! / bin / bash

export ROBOT_SYSLOG_FILE = /tmp/syslog.txt

export ROBOT_SYSLOG_LEVEL = DEBUG

robot --name Syslog_example chemin / to / tests

4 Extension du cadre du robot
 4.1 Créer des bibliothèques de tests
 4.2 Interface de bibliothèque distante
 4.3 Interface auditeur
 4.4 Extension du pot du cadre robot

4.1 Créer des bibliothèques de tests

Les capacités de test réelles de Robot Framework sont fournies par les
bibliothèques de tests. Il existe de nombreuses bibliothèques existantes, dont
certaines sont même regroupées avec le framework de base, mais il est encore
souvent nécessaire d'en créer de nouvelles. Cette tâche n'est pas trop compliquée
car, comme l'illustre ce chapitre, l'API de bibliothèque de Robot Framework est
simple et directe.

 4.1.1 Introduction
o Langages de programmation supportés
o Différentes API de bibliothèque de test
 4.1.2 Créer une classe ou un module de bibliothèque de test
o Test des noms de bibliothèque
o Fournir des arguments pour tester les bibliothèques
o Portée de la bibliothèque de test
o Spécification de la version de la bibliothèque
o Spécification du format de la documentation
o Bibliothèque agissant comme auditeur
 4.1.3 Création de mots-clés statiques
o Quelles méthodes sont considérées comme des mots clés?
o Noms de mots clés
o Tags de mots clés
o Arguments de mots clés
o Valeurs par défaut aux mots-clés
o Nombre variable d'arguments ( *varargs)
o Arguments de mots clés gratuits ( **kwargs)
o Types d'argument
o Utiliser des décorateurs
o Incorporation d'arguments dans des noms de mots clés
 4.1.4 Communication avec le framework Robot
o Signaler le statut du mot clé
o Arrêt de l'exécution du test
o Poursuite de l'exécution des tests malgré les échecs
o Informations de journalisation
o API de journalisation programmatique
o Enregistrement lors de l'initialisation de la bibliothèque
o Valeurs de retour
o Communication lors de l'utilisation de threads
 4.1.5 Distribution des bibliothèques de test
 o Documentation des bibliothèques
o Test des bibliothèques
o Bibliothèques d'emballage
o Mots clés dépréciés
 4.1.6 API de bibliothèque dynamique
o Obtenir des noms de mots clés
o Mots clés en cours d'exécution
o Obtenir des arguments de mots clés
o Obtenir des mots-clés
o Obtenir de la documentation sur les mots clés
o Obtenir la documentation générale de la bibliothèque
o Syntaxe des arguments nommés avec bibliothèques dynamiques
o Arguments de mots clés gratuits avec bibliothèques dynamiques
o Résumé
 4.1.7 API de bibliothèque hybride
o Obtenir des noms de mots clés
o Mots clés en cours d'exécution
o Obtention des arguments et de la documentation sur les mots clés
o Résumé
 4.1.8 Utilisation des modules internes de Robot Framework
o API disponibles
o Utilisation de la bibliothèque BuiltIn
 4.1.9 Extension des bibliothèques de test existantes
o Modification du code source d'origine
o Utiliser l'héritage
o Utiliser d'autres bibliothèques directement
o Obtenir une instance de bibliothèque active à partir de Robot Framework
o Bibliothèques utilisant l'API dynamique ou hybride

4.1.1 Introduction
Langages de programmation supportés
Robot Framework lui-même est écrit avec Python et teste naturellement les
bibliothèques en l'étendant peut être implémenté en utilisant le même langage. Lors
de l'exécution du framework sur Jython , les bibliothèques peuvent également être
implémentées en Java . Le code Python pur fonctionne à la fois sur Python et
Jython, en supposant qu'il n'utilise pas de syntaxe ou de modules qui ne sont pas
disponibles sur Jython. Lorsque vous utilisez Python, il est également possible
d'implémenter des bibliothèques avec C en utilisant l' API Python C , bien qu'il soit
souvent plus facile d'interagir avec du code C à partir de bibliothèques Python
utilisant le module ctypes .

Les bibliothèques implémentées à l'aide de ces langages pris en charge de manière

native peuvent également servir d'enveloppes aux fonctionnalités implémentées à
l'aide d'autres langages de programmation. Un bon exemple de cette approche est
la bibliothèque distante , et une autre approche largement utilisée consiste à exécuter
des scripts ou des outils externes en tant que processus distincts.
Pointe

Didacticiel Python pour la bibliothèque de tests de la structure de robots Les

développeurs couvrent suffisamment de langage Python pour commencer à écrire des
bibliothèques de tests en utilisant ce langage. Il contient également un exemple simple de
bibliothèque et des cas de test que vous pouvez exécuter et étudier de toute autre manière sur
votre machine.

Différentes API de bibliothèque de test

Robot Framework possède trois API de bibliothèque de test différentes.

API statique

L'approche la plus simple est d'avoir un module (en Python) ou une classe (en
Python ou Java) avec des méthodes qui correspondent directement aux noms de
mots-clés . Les mots-clés prennent également les mêmes arguments que les méthodes
les mettant en œuvre. Les mots-clés signalent des échecs avec des exceptions,
se connectent en écrivant à la sortie standard et peuvent renvoyer des valeurs à l'aide
de l' returninstruction.

API dynamique

Les bibliothèques dynamiques sont des classes qui implémentent une méthode pour
obtenir les noms des mots-clés qu'elles implémentent, ainsi qu'une autre méthode
pour exécuter un mot-clé nommé avec des arguments donnés. Les noms des mots-
clés à implémenter, ainsi que leur exécution, peuvent être déterminés
dynamiquement lors de l'exécution, mais la génération de rapports sur l'état, la
journalisation et le renvoi est similaire à celle de l'API statique.

API hybride

C'est un hybride entre l'API statique et l'API dynamique. Les bibliothèques sont des
classes avec une méthode indiquant quels mots-clés elles implémentent, mais ces
mots-clés doivent être disponibles directement. Tout le reste sauf la découverte des
mots-clés implémentés est similaire à celle de l'API statique.

Toutes ces API sont décrites dans ce chapitre. Tout est basé sur le fonctionnement
de l'API statique, ses fonctions sont donc abordées en premier. La façon dont l' API
de la bibliothèque dynamique et l' API de la bibliothèque hybride en diffèrent est ensuite
abordée dans des sections spécifiques.

Les exemples de ce chapitre concernent principalement l'utilisation de Python, mais

ils devraient également être faciles à comprendre pour les développeurs Java
uniquement. Dans les quelques cas où les API ont des différences, les deux
utilisations sont expliquées avec des exemples adéquats.
4.1.2 Créer une classe ou un module de bibliothèque de
test
Les bibliothèques de test peuvent être implémentées en tant que modules Python et
classes Python ou Java.

Test des noms de bibliothèque

Le nom d'une bibliothèque de tests utilisée lors de l'importation d'une bibliothèque
est identique à celui du module ou de la classe qui l'implémente. Par exemple, si
vous avez un module Python MyLibrary(c'est-à-dire le fichier MyLibrary.py ), il
créera une bibliothèque nommée MyLibrary . De même, une classe
Java YourLibrary, lorsqu'elle n'est dans aucun package, crée une bibliothèque avec
exactement ce nom.

Les classes Python sont toujours dans un module. Si le nom d'une classe
implémentant une bibliothèque est identique au nom du module, Robot Framework
permet de supprimer le nom de la classe lors de l'importation de la
bibliothèque. Par exemple, la classe MyLibdans le fichier MyLib.py peut être utilisée
comme bibliothèque avec simplement le nom MyLib . Cela fonctionne également
avec des sous-modules, de sorte que si, par exemple, le parent.MyLibmodule a une
classe MyLib, il doit être importé en utilisant
uniquement parent.MyLib fonctionne. Si le nom du module et celui de la classe
sont différents, les bibliothèques doivent être utilisées à la fois avec les noms de
module et de classe, tels que mymodule.MyLibrary ou parent.submodule.MyLib .

Les classes Java dans un package autre que celui par défaut doivent être utilisées
avec le nom complet. Par exemple, la classe MyLibdans
le com.mycompany.myproject package doit être importée avec le
nom com.mycompany.myproject.MyLib .

Remarque

La suppression des noms de classe avec des sous-modules ne fonctionne que dans Robot
Framework 2.8.4 et versions ultérieures. Avec les versions antérieures, vous devez également
inclure le nom de la classe comme parent.MyLib.MyLib .

Pointe

Si le nom de la bibliothèque est très long, par exemple lorsque le nom du package Java est
long, il est recommandé de donner à la bibliothèque un alias plus simple en utilisant
la syntaxe WITH NAME .

Fournir des arguments pour tester les bibliothèques

Toutes les bibliothèques de tests implémentées en tant que classes peuvent prendre
des arguments. Ces arguments sont spécifiés dans la table Setting après le nom de
la bibliothèque, et lorsque Robot Framework crée une instance de la bibliothèque
importée, il les transmet à son constructeur. Les bibliothèques implémentées en tant
que module ne peuvent pas prendre d'argument, donc essayer de les utiliser entraîne
une erreur.

Le nombre d'arguments requis par la bibliothèque est le même que le nombre

d'arguments acceptés par le constructeur de la bibliothèque. Les valeurs par défaut
et le nombre variable d'arguments fonctionnent de la même manière qu'avec
les arguments de mot-clé , à l'exception du fait qu'il n'y a pas de prise en charge des
arguments variables pour les bibliothèques Java. Les arguments transmis à la
bibliothèque, ainsi que le nom de la bibliothèque lui-même, peuvent être spécifiés à
l'aide de variables. Il est donc possible de les modifier, par exemple à partir de la
ligne de commande.
*** Paramètres ***
Bibliothèque MyLibrary 10.0.0.1 8080
Bibliothèque AnotherLib $ { VAR }

Exemples d'implémentations, la première en Python et la seconde en Java, pour les

bibliothèques utilisées dans l'exemple ci-dessus:
à partir de l' exemple d' importation Connexion

classe MyLibrary :

def __init__ ( self , host , port = 80 ):

self . _conn = Connexion ( hôte , int ( port ))

def send_message ( self , message ):

self . _conn . envoyer ( message )
classe publique AnotherLib {

paramètre de chaîne privé = null ;

public AnotherLib ( paramètre String ) { setting = setting ; }

public void doSomething () {

si paramétré . est égal à ( "42" ) {
// fait quelque chose ...
}
}
}

Portée de la bibliothèque de test

Les bibliothèques implémentées en tant que classes peuvent avoir un état interne,
qui peut être modifié par des mots-clés et par des arguments au constructeur de la
bibliothèque. Étant donné que l'état peut affecter le comportement réel des mots
clés, il est important de s'assurer que les modifications apportées dans un scénario
de test n'affectent pas accidentellement d'autres scénarios de test. Ces types de
dépendances peuvent créer des problèmes de débogage difficiles, par exemple,
lorsque de nouveaux scénarios de test sont ajoutés et qu'ils utilisent la bibliothèque
de manière incohérente.

Robot Framework tente de garder les scénarios de test indépendants les uns des
autres: par défaut, il crée de nouvelles instances de bibliothèques de tests pour
chaque scénario de test. Cependant, ce comportement n'est pas toujours
souhaitable, car les cas de test doivent parfois pouvoir partager un état commun. De
plus, toutes les bibliothèques n'ont pas d'état et la création de nouvelles instances
n'est tout simplement pas nécessaire.

Les bibliothèques de test peuvent contrôler le moment où de nouvelles

bibliothèques sont créées avec un attribut de classe ROBOT_LIBRARY_SCOPE. Cet
attribut doit être une chaîne et peut avoir les trois valeurs suivantes:
TEST CASE
Une nouvelle instance est créée pour chaque scénario de test. Une éventuelle
installation de la suite et le démontage de la suite partagent une autre
instance. Ceci est la valeur par défaut.
TEST SUITE
Une nouvelle instance est créée pour chaque suite de tests. Les suites de tests
de niveau le plus bas, créées à partir de fichiers de scénarios de test et
contenant des scénarios de test, possèdent leurs propres instances et les
suites de niveau supérieur reçoivent toutes leurs propres instances pour leurs
configurations et démontages possibles.
GLOBAL
Une seule instance est créée au cours de l'exécution du test et elle est
partagée par tous les scénarios de test et suites de tests. Les bibliothèques
créées à partir de modules sont toujours globales.

Remarque

Si une bibliothèque est importée plusieurs fois avec des arguments différents , une nouvelle
instance est créée chaque fois quelle que soit l'étendue.

Lorsque les étendues TEST SUITEou GLOBALsont utilisées avec des bibliothèques de
test avec un état, il est recommandé que les bibliothèques disposent d'un mot-clé
spécial pour nettoyer l'état. Ce mot-clé peut ensuite être utilisé, par exemple, dans
une configuration ou une suppression de suite pour garantir que les scénarios de
test des prochaines suites de tests puissent démarrer à partir d'un état connu. Par
exemple, SeleniumLibrary utilise l’ GLOBALétendue pour permettre l’utilisation du
même navigateur dans différents scénarios de test sans avoir à le rouvrir, ainsi que
le mot clé Fermer tous les navigateurs pour fermer facilement tous les navigateurs
ouverts.
Exemple de bibliothèque Python utilisant la TEST SUITEportée:

classe ExampleLibrary :

ROBOT_LIBRARY_SCOPE = 'SUITE DE TEST'

def __init__ ( self ):

self . _counter = 0

def count ( self ):

self . _counter + = 1
imprimer soi-même . _compteur

def clear_counter ( self ):

self . _counter = 0

Exemple de bibliothèque Java utilisant la GLOBALportée:

classe publique ExampleLibrary {

final statique public String ROBOT_LIBRARY_SCOPE = "GLOBAL" ;

private int counter = 0 ;

nombre de vides publics () { compteur + = 1 ; Système . out . println

( compteur ); }

public void clearCounter () {

counter = 0 ;
}
}

Spécification de la version de la bibliothèque

Lorsqu'une bibliothèque de tests est utilisée, Robot Framework tente de déterminer
sa version. Ces informations sont ensuite écrites dans le Syslog pour fournir des
informations de débogage. Outil de documentation de la bibliothèque Libdoc écrit
également ces informations dans les documentations générées.

Les informations de version sont lues depuis l'attribut ROBOT_LIBRARY_VERSION, de

même que la portée de la bibliothèque de test est
lue ROBOT_LIBRARY_SCOPE. Si ROBOT_LIBRARY_VERSIONn'existe pas, les informations
sont essayées pour être lues à partir d' __version__attribut. Ces attributs doivent
être des attributs de classe ou de module, selon que la bibliothèque est implémentée
en tant que classe ou module. Pour les bibliothèques Java, l'attribut version doit être
déclaré comme static final.

Un exemple de module Python utilisant __version__:

__version__ = '0.1'
def mot-clé ():
passe

Une classe Java utilisant ROBOT_LIBRARY_VERSION:

classe publique VersionExample {

final statique public String ROBOT_LIBRARY_VERSION = "1.0.2" ;

mot clé public vide () { } }

Spécification du format de la documentation

À partir de Robot Framework 2.7.5, l'outil de documentation de la
bibliothèque Libdoc prend en charge la documentation dans plusieurs formats. Si
vous voulez utiliser autre chose que le formatage de la documentation de Robot
Framework , vous pouvez spécifier le format dans le code source en utilisant
l' ROBOT_LIBRARY_DOC_FORMATattribut de la même manière que l' étendue et
la version sont définies avec leurs propres ROBOT_LIBRARY_*attributs.

Les valeurs sensibles à la casse possibles pour le format de la documentation

sont ROBOT(par défaut), HTML, TEXT(texte brut) et reST( reStructuredText ). L'utilisation
du reSTformat nécessite que le module docutils soit installé lorsque la
documentation est générée.

La définition du format de la documentation est illustrée par les exemples Python et

Java suivants, qui utilisent respectivement les formats reStructuredText et
HTML. Voir la section Documentation des bibliothèques et le chapitre Libdoc pour plus
d'informations sur la documentation des bibliothèques de tests en général.
"" "Une bibliothèque pour * le format de documentation * à des fins de
démonstration.

Cette documentation est créée à l'aide de reStructuredText__. Voici un lien

vers le seul \ `Mot-clé \`.

__ http://docutils.sourceforge.net
"" "

ROBOT_LIBRARY_DOC_FORMAT = 'reST'

def mot-clé ():

"" ** ** Rien à voir ici. Même pas dans le tableau ci-dessous.

======= ===== ===== Le

tableau ici n’a
rien à voir.
======= ===== =====
"" "
passe
/ **
* Une bibliothèque à des fins de démonstration de <i> format de
documentation </ i>.
*
* Cette documentation est créée à l’aide de <a
href="http://www.w3.org/html"> HTML </a>.
* Voici un lien vers le seul `Mot-clé`.
* /
classe publique DocFormatExample {

final statique public String ROBOT_LIBRARY_DOC_FORMAT = "HTML" ;

/ ** <b> Rien </ b> à voir ici. Même pas dans le tableau ci-dessous.
*
* <table>
* <tr> <td> Table </ td> <td> ici </ td> <td> a </ td> </ tr>
* <tr> <td> rien </ td> < td> to </ td> <td> voir. </ td> </ tr>
* </ table>
* /
public void keyword () {
}
}

Bibliothèque agissant comme auditeur

L'interface d'écoute permet aux écouteurs externes d'obtenir des notifications sur
l'exécution du test. Ils sont appelés, par exemple, lorsque les suites, les tests et les
mots-clés commencent et se terminent. Parfois, l'obtention de telles notifications est
également utile pour les bibliothèques de tests et elles peuvent enregistrer un
écouteur personnalisé en utilisant l'ROBOT_LIBRARY_LISTENERattribut. La valeur de
cet attribut devrait être une instance de l'écouteur à utiliser, éventuellement la
bibliothèque elle-même. Pour plus d'informations et des exemples, consultez la
section Test des bibliothèques en tant qu'écouteurs .

4.1.3 Création de mots-clés statiques

Quelles méthodes sont considérées comme des mots clés?
Lorsque l'API de bibliothèque statique est utilisée, Robot Framework utilise la
réflexion pour savoir quelles méthodes publiques la classe ou le module de
bibliothèque contient. Cela exclura toutes les méthodes commençant par un trait de
soulignement (à moins d' utiliser un nom de mot-clé personnalisé ), et avec les
bibliothèques Java, les méthodes implémentées uniquement dans la classe de base
implicite java.lang.Objectsont également exclues. Toutes les méthodes non
ignorées sont considérées comme des mots clés. Par exemple, les bibliothèques
Python et Java ci-dessous implémentent un seul mot clé, My Keyword .
classe MyLibrary :

def my_keyword ( self , arg ):

retourne moi-même . _helper_method ( arg )

def _helper_method ( self , arg ):

 retourne l' argument . en haut ()
classe publique MyLibrary {

public String myKeyword ( String arg ) {

return helperMethod ( arg );
}

private String helperMethod ( String arg ) {

return arg . toUpperCase ();
}
}

Lors de l'implémentation d'une bibliothèque en tant que classe Python ou Java, les
méthodes des classes de base possibles sont également considérées comme des
mots clés. Lors de l'implémentation d'une bibliothèque en tant que module Python,
les fonctions possibles importées dans l'espace de noms du module deviennent
également des mots-clés. Par exemple, si le module ci-dessous serait utilisé en tant
que bibliothèque, il contiendrait des mots-clés Exemple de mot - clé , Deuxième
exemple et également Thread actuel .
à partir de threading import current_thread

def example_keyword ():

print 'En cours d'exécution dans le thread " % s ".' %
current_thread () . prénom

def second_example ():

passe

Un moyen simple d'éviter que les fonctions importées ne deviennent des mots-clés
consiste à importer uniquement des modules (par exemple import threading) et à
utiliser des fonctions via le module (par
exemple threading.current_thread()). Alternativement, les fonctions peuvent
recevoir un alias commençant par un trait de soulignement à l’importation (par
exemple from threading import current_thread as _current_thread).

Un moyen plus explicite de limiter les fonctions devenant des mots-clés consiste à
utiliser l' __all__attribut de niveau de module que Python lui-même utilise à des fins
similaires . S'il est utilisé, seules les fonctions répertoriées peuvent être des mots
clés. Par exemple, la bibliothèque ci-dessous implémente uniquement les mots-
clés Exemple de mot - clé et deuxième exemple .
à partir de threading import current_thread

__all__ = [ 'example_keyword' , 'second_example' ]

def example_keyword ():

print 'En cours d'exécution dans le thread " % s ".' %
current_thread () . prénom
def second_example ():
passe

def not_exposed_as_keyword ():

passe

Noms de mots clés

Les noms de mots-clés utilisés dans les données de test sont comparés aux noms de
méthode pour trouver la méthode implémentant ces mots-clés. La comparaison de
noms est insensible à la casse, et les espaces et les traits de soulignement sont
également ignorés. Par exemple, la méthode est hellomappée sur le mot-
clé Bonjour , bonjour ou même bonjour . De même,
les méthodes do_nothinget doNothingpeuvent être utilisées comme mot-clé Do
Nothing dans les données de test.

Exemple de bibliothèque Python implémentée en tant que module dans

le fichier MyLibrary.py :
def hello ( name ):
affiche "Bonjour, % s !" % nom

def do_nothing ():

passe

Exemple de bibliothèque Java implémentée en tant que classe dans

le fichier MyLibrary.java :
classe publique MyLibrary {

public void hello ( Nom de la chaîne ) { Système . out . println (

"Bonjour" + nom + "!" ); }

public void doNothing () {

}

L'exemple ci-dessous illustre comment les bibliothèques d'exemple ci-dessus

peuvent être utilisées. Si vous voulez essayer cela vous-même, assurez-vous que la
bibliothèque se trouve dans le chemin de recherche du module .
*** Paramètres ***
Bibliothèque MyLibrary

*** Cas de test ***

Mon test
Ne fais rien
Bonjour monde

Utilisation d'un nom de mot clé personnalisé

Il est possible d'exposer un nom différent pour un mot clé au lieu du nom de mot
clé par défaut qui correspond au nom de la méthode. Cela peut être réalisé en
définissant l' robot_nameattribut de la méthode sur le nom personnalisé
souhaité. Ceci est généralement plus facile en utilisant
le robot.api.deco.keyworddécorateur comme suit:
à partir du mot-clé d' importation robot.api.deco

@keyword ( 'Login Via User Panel' )

def login ( nom d'utilisateur , mot de passe ):
# ...
*** Cas de test ***
Mon test
Connexion via le panneau utilisateur $ { username } $ { password }

L'utilisation de ce décorateur sans argument n'aura aucun effet sur le nom du mot
clé exposé, mais définira toujours l' robot_nameattribut. Cela permet aux méthodes de
marquage d'exposer en tant que mots-clés sans modifier réellement les noms de mots-
clés. À partir de Robot Framework 3.0.2, les méthodes qui possèdent
l' robot_name attribut créent également des mots-clés même si le nom de la méthode
commence par un trait de soulignement.

La définition d'un nom de mot-clé personnalisé peut également permettre aux mots-
clés de bibliothèque d'accepter des arguments à l'aide de la syntaxe des arguments
incorporés .

Tags de mots clés

À partir de Robot Framework 2.9, les mots-clés de la bibliothèque et les mots - clés
des utilisateurs peuvent avoir des balises. Les mots-clés de la bibliothèque peuvent
les définir en définissant l' robot_tags attribut de la méthode sur une liste de balises
souhaitées. Le robot.api.deco.keyword décorateur peut être utilisé comme
raccourci pour définir cet attribut lorsqu'il est utilisé comme suit:
à partir du mot-clé d' importation robot.api.deco

@keyword ( tags = [ 'tag1' , 'tag2' ])

def login ( nom d'utilisateur , mot de passe ):
# ...

@keyword ( 'Nom personnalisé' , [ 'tags' , 'ici' ])

def another_example ():
# ...

Une autre option pour définir des balises est de leur donner la dernière ligne de
la documentation du mot - clé avec un Tags:préfixe et de les séparer par une
virgule. Par exemple:
def login ( nom d'utilisateur , mot de passe ):
"" "Connectez-vous à l'utilisateur.
 Tags: tag1, tag2
"" "
# ...

Arguments de mots clés

Avec une API statique et hybride, les informations sur le nombre d’arguments
requis par un mot-clé proviennent directement de la méthode qui les
implémente. Les bibliothèques utilisant l' API de bibliothèque dynamique ont d'autres
moyens de partager ces informations. Par conséquent, cette section ne les concerne
pas.

La situation la plus courante et la plus simple est lorsqu'un mot clé nécessite un
nombre exact d'arguments. Dans ce cas, les méthodes Python et Java prennent
simplement ces arguments exactement. Par exemple, une méthode implémentant un
mot-clé sans argument ne prend pas non plus d'argument, une méthode
implémentant un mot-clé avec un argument prend également un argument, etc.

Exemple de mots-clés Python prenant différents nombres d'arguments:

def no_arguments ():
print "Le mot-clé n'a pas d'arguments."

def one_argument ( arg ):

print "Le mot clé a un argument ' % s '." % arg

def three_arguments ( a1 , a2 , a3 ):
print "Le mot clé a trois arguments ' % s ', ' % s ' et ' % s '." %
( a1 , a2 , a3 )

Remarque

Une limitation majeure des bibliothèques Java utilisant l'API de bibliothèque statique est
qu'elles ne prennent pas en charge la syntaxe d'argument nommé . S'il s'agit d'un bloqueur, il
est possible d'utiliser Python ou de basculer vers l' API de bibliothèque dynamique .

Valeurs par défaut aux mots-clés

Il est souvent utile que certains des arguments utilisés par un mot clé aient des
valeurs par défaut. Python et Java ont une syntaxe différente pour gérer les valeurs
par défaut des méthodes, et la syntaxe naturelle de ces langages peut être utilisée
lors de la création de bibliothèques de tests pour Robot Framework.

Valeurs par défaut avec Python

En Python, une méthode a toujours exactement une implémentation et les valeurs

par défaut possibles sont spécifiées dans la signature de la méthode. La syntaxe,
familière à tous les programmeurs Python, est illustrée ci-dessous:
def one_default ( arg = 'default' ):
print "L'argument a la valeur % s " % arg

def multiple_defaults ( arg1 , arg2 = 'default 1' , arg3 = 'default 2'

):
print "Arguments obtenus % s , % s et % s " % ( arg1 , arg2 , arg3
)

Le premier mot-clé ci-dessus peut être utilisé avec des arguments zéro ou un. Si
aucun argument n'est donné, argobtient la valeur default. S'il existe un
argument, argrécupère cette valeur et l'appel du mot clé avec plusieurs arguments
échoue. Dans le deuxième exemple, un argument est toujours requis, mais le
second et le troisième ont des valeurs par défaut. Il est donc possible d'utiliser le
mot clé avec un à trois arguments.
*** Cas de test ***
Les défauts
Un défaut
Un argument par défaut
Plusieurs valeurs par défaut requises arg
Plusieurs valeurs par défaut requises arg facultatif
Plusieurs valeurs par défaut requises arg facultatif 1 facultatif 2

Valeurs par défaut avec Java

En Java, une méthode peut avoir plusieurs implémentations avec des signatures
différentes. Robot Framework considère toutes ces implémentations comme un seul
mot clé, qui peut être utilisé avec des arguments différents. Cette syntaxe peut donc
être utilisée pour prendre en charge les valeurs par défaut. Ceci est illustré par
l'exemple ci-dessous, qui est fonctionnellement identique à l'exemple précédent de
Python:
public void oneDefault ( String arg ) {
Système . out . println ( "L'argument a une valeur" + arg );
}

public void oneDefault () {

oneDefault ( "default" );
}

public void multipleDefaults ( String arg1 , String arg2 , String

arg3 ) {
Système . out . println ( "Arguments obtenus " + arg1 + "," +
arg2 + "et" + arg3 );
}

void multipleDefaults public ( String arg1 , String arg2 ) {

multipleDefaults ( arg1 , arg2 , "default 2" );
}

public void multipleDefaults ( String arg1 ) {

multipleDefaults ( arg1 , "default 1" );
}
Nombre variable d'arguments ( *varargs)
Robot Framework prend également en charge les mots clés qui prennent un nombre
quelconque d'arguments. De même que pour les valeurs par défaut, la syntaxe
réelle à utiliser dans les bibliothèques de tests est différente en Python et en Java.

Nombre variable d'arguments avec Python

Python supporte les méthodes acceptant un nombre quelconque d'arguments. La

même syntaxe fonctionne dans les bibliothèques et, comme le montrent les
exemples ci-dessous, elle peut également être combinée à d’autres façons de
spécifier des arguments:
def any_arguments ( * args ):
print "Arguments
obtenus :" pour arg dans args :
print arg

def one_required ( requis , * autres ):

print "Obligatoire: % s \ n Autres:" % requis
pour arg dans d' autres :
print arg

def also_defaults ( req , def1 = "default 1" , def2 = "default 2" , *

rest ):
print req , def1 , def2 , rest
*** Cas de test ***
Varargs
Des arguments
Tout argument Arguments
Arguments arg 1 arg 2 arg 3 arg 4 arg 5
Un requis requis arg
Un requis requis arg un autre encore un autre
Aussi par défaut requis
Aussi les valeurs par défaut requises ces deux ont des valeurs par
défaut
Aussi par défaut 1 2 3 4 5 6

Nombre variable d'arguments avec Java

Robot Framework prend en charge la syntaxe Java varargs pour définir un nombre
variable d'arguments. Par exemple, les deux mots-clés suivants sont
fonctionnellement identiques aux exemples Python ci-dessus avec les mêmes noms:
public void anyArguments ( String ... varargs ) {
Système . out . println ( "Got arguments:" );
pour ( String arg : varargs ) {
System . out . println ( arg );
}
}

public void oneRequired ( chaîne requise , chaîne ... autres ) {

Système . out . println ( "Obligatoire:" + obligatoire + "\ nSi:"
);
 for ( String arg : others ) {
Système . out . println ( arg );
}
}

Il est également possible d'utiliser un nombre variable d'arguments en ayant un

tableau ou, à partir de Robot Framework 2.8.3, java.util.Listcomme dernier
argument, ou deuxième à dernier si des arguments de mots clés libres (** kwargs) sont
utilisés. Ceci est illustré par les exemples suivants fonctionnellement identiques aux
précédents:
public void anyArguments ( String [] varargs ) {
System . out . println ( "Got arguments:" );
pour ( String arg : varargs ) {
System . out . println ( arg );
}
}

public void oneRequired ( String requis , List < String > others ) {
System . out . println ( "Obligatoire:" + obligatoire + "\ nSi:" );
for ( String arg : others ) {
Système . out . println ( arg );
}
}

Remarque

Seul java.util.Listest pris en charge en tant que varargs, aucun de ses sous-types.

La prise en charge d'un nombre variable d'arguments avec des mots-clés Java a une
limitation: elle ne fonctionne que lorsque les méthodes ont une signature. Il n'est
donc pas possible d'avoir des mots-clés Java avec les deux valeurs par défaut et
varargs. En plus de cela, seuls Robot Framework 2.8 et plus récents prennent en
charge l'utilisation de varargs avec les constructeurs de bibliothèques .

Arguments de mots clés gratuits ( **kwargs)

Robot Framework 2.8 a ajouté la prise en charge des arguments de mots clés
gratuits en utilisant la **kwargssyntaxe de Python . L'utilisation de la syntaxe dans
les données de test est décrite dans lasection Arguments relatifs aux mots clés
libres sous Création de scénarios de test . Dans cette section, nous allons voir comment
l'utiliser dans des bibliothèques de tests personnalisées.

Arguments de mots clés gratuits avec Python

Si vous connaissez déjà le fonctionnement de kwargs avec Python, il est assez

simple de comprendre comment ils fonctionnent avec les bibliothèques de test de
Robot Framework. L'exemple ci-dessous montre les fonctionnalités de base:
def exemple_keyword ( ** stuff ):
pour le nom , valeur dans les choses . items ():
 nom d' impression , valeur
*** Cas de test ***
Arguments de mots clés
Exemple Mot clé hello = world # Logs 'Bonjour tout le monde'. Exemple
de mot-clé foo = 1 bar = 42 # Logs 'foo 1' et 'bar 42'.

Fondamentalement, tous les arguments à la fin du mot-clé call qui utilisent

la syntaxe de l'argument nommé name=value et qui ne correspondent à aucun autre
argument sont transmis au mot-clé en tant que kwargs. Pour éviter d'utiliser une
valeur littérale comme foo=quuxun argument de mot-clé gratuit, il doit
être échappé comme foo\=quux.

L'exemple suivant montre comment les arguments normaux, varargs et kwargs

fonctionnent ensemble:
def various_args ( arg , * varargs , ** kwargs ):
print 'arg:' , arg
pour value dans varargs :
print 'vararg:' , valeur
pour nom , valeur pour tri ( kwargs . items ()):
print 'kwarg: ' , nom , valeur
*** Cas de test ***
Positionnel
Divers Args hello world # Logs 'arg: hello' et 'vararg: world'.

Nommé
Divers Args arg = valeur # Logs 'arg: value'.

Kwargs
Divers args a = 1 b = 2 c = 3 # Logs 'kwarg: a 1', 'kwarg: b 2' et
'kwarg: c 3'. Divers Args c = 3 a = 1 b = 2 # Identique à ci-dessus.
L'ordre n'a pas d'importance.

Positionnel et kwargs
Args divers 1 2 kw = 3 # Logs 'arg: 1', 'vararg: 2' et 'kwarg: kw 3'.

Nommé et kwargs
Divers Args arg = valeur hello = world # Logs 'arg: value' et 'kwarg:
hello world'. Various Args hello = world arg = valeur # Identique à ci-
dessus. L'ordre n'a pas d'importance.

Pour un exemple concret d'utilisation d'une signature exactement comme dans

l'exemple ci-dessus, voir Exécuter les mots clés Processus et Démarrer le mot clé
dans la bibliothèque de processus .

Arguments de mots clés gratuits avec Java

À partir de Robot Framework 2.8.3, les bibliothèques Java prennent également en

charge la syntaxe des arguments de mots clés gratuits. Java lui-même n'a pas de
syntaxe kwargs, mais les mots-clés peuvent avoir java.util.Mappour dernier
argument de spécifier qu'ils acceptent kwargs.

Si un mot-clé Java accepte kwargs, Robot Framework compresse automatiquement

tous les arguments dans la name=valuesyntaxe à la fin du mot-clé call dans un Mapet
le transmet au mot-clé. Par exemple, les exemples de mots-clés suivants peuvent
être utilisés exactement comme les exemples Python précédents:
public void exampleKeyword ( Map < String , String > stuff ):
for ( Clé de chaîne : stuff . keySet ()) Système . out . println (
key + "" + stuff . get ( key ));

public void variousArgs ( String arg , List < String > varargs , Map
< String , Object > kwargs ):
Système . out . println ( "arg:" + arg );
for ( String varg : varargs )
System . out . println ( "vararg:" + varg );
pour ( clé de chaîne : kwargs . keySet ())
Système . out . println ( "kwarg:" + key + "" + kwargs . get
( key ));

Remarque

Le type de l'argument kwargs doit être exactement java.util.Map, pas l'un de ses sous-
types.

Remarque

De même que pour le support varargs , un mot clé prenant en charge kwargs ne peut pas avoir
plus d’une signature.

Types d'argument
Normalement, les arguments de mots-clés sont fournis à Robot Framework en tant
que chaînes. Si les mots-clés nécessitent d'autres types, il est possible d'utiliser
des variables ou de convertir des chaînes en types requis dans les mots-
clés. Avec Java , les types de base sont également forcés automatiquement.

Types d'argument avec Python

Étant donné que les arguments de Python ne contiennent pas d'informations de

type, il n'est pas possible de convertir automatiquement des chaînes vers d'autres
types lors de l'utilisation de bibliothèques Python. L'appel d'une méthode Python
implémentant un mot clé avec un nombre correct d'arguments réussit toujours, mais
l'exécution échoue ultérieurement si les arguments sont
incompatibles. Heureusement, avec Python, il est simple de convertir des
arguments en types appropriés dans les mots-clés:
def connect_to_host ( adresse , port = 25 ):
 port = int ( port )
# ...

Types d'argument avec Java

Les arguments pour les méthodes Java ont des types et tous les types de base sont
gérés automatiquement. Cela signifie que les arguments qui sont des chaînes
normales dans les données de test sont forcés à corriger le type à l'exécution. Les
types pouvant être forcés sont:

 types entiers ( byte, short, int, long)

 types à virgule flottante ( floatet double)
 le booleantype
 versions d'objet des types ci-dessus, par exemple java.lang.Integer

La coercition est effectuée pour les arguments ayant le même type ou un type
compatible pour toutes les signatures de la méthode par mot-clé. Dans l'exemple
suivant, la conversion peut être effectuée pour les mots
clés doubleArgument et compatibleTypes, mais pas pour conflictingTypes.
public double vide doubleArgument ( double arg ) {}

void compatibleTypes publics ( String arg1 , Integer arg2 ) {}

void compatibleTypes publics ( String arg2 , Integer arg2 , Boolean arg3 )
{}

void conflictingTypes publics ( String arg1 , int arg2 ) {}

void conflictingTypes publics ( int arg1 , String arg2 ) {}

La coercition fonctionne avec les types numériques si les données de test ont une
chaîne contenant un nombre et avec le type booléen, les données doivent contenir
une chaîne trueou false. La coercition n'est effectuée que si la valeur d'origine
était une chaîne provenant des données de test, mais il est bien entendu toujours
possible d'utiliser des variables contenant des types corrects avec ces mots
clés. L'utilisation de variables est la seule option si les mots-clés ont des signatures
en conflit.
*** Cas de test ***
Coercition
Double argument 3.14
Double Argument 2e16
Types compatibles Bonjour, monde! 1234
Types compatibles Hi again! -10 vrai

Pas de coercition
Double Argument $ { 3.14 }
Types en conflit 1 $ { 2 } # doit utiliser des variables Types
en conflit $ { 1 } 2
À partir de Robot Framework 2.8, la coercition de type argument fonctionne
également avec les constructeurs de bibliothèques Java .

Utiliser des décorateurs

Lors de l'écriture de mots-clés statiques, il est parfois utile de les modifier avec les
décorateurs de Python. Cependant, les décorateurs modifient les signatures de
fonction et peuvent confondre l'introspection de Robot Framework lors de la
détermination des arguments acceptés par les mots clés. Ceci est particulièrement
problématique lors de la création de la documentation de la bibliothèque
avec Libdoc et lors de l'utilisation de RIDE . Pour éviter ce problème, n'utilisez pas
de décorateurs ou utilisez le module de décoration pratique pour créer des décorateurs
préservant les signatures.

Incorporation d'arguments dans des noms de mots clés

Les mots-clés de la bibliothèque peuvent également accepter les arguments
transmis à l'aide de la syntaxe Embedded
Argument . Le robot.api.deco.keyworddécorateur peut être utilisé pour créer un nom
de mot-clé personnalisé pour le mot-clé qui inclut la syntaxe souhaitée.

à partir du mot-clé d' importation robot.api.deco

@keyword ( 'Add $ {quantity: \ d +} Copies de $ {item} To Cart' )

def add_copies_to_cart ( quantité , article ):
# ...
*** Cas de test ***
Mon test
Ajouter 7 copies de café au panier

4.1.4 Communication avec le framework Robot

Une fois qu'une méthode implémentant un mot-clé est appelée, elle peut utiliser
n'importe quel mécanisme pour communiquer avec le système testé. Il peut
également envoyer des messages au fichier journal de Robot Framework, renvoyer
des informations pouvant être enregistrées dans des variables et, surtout, signaler si
le mot clé a réussi ou non.

Signaler le statut du mot clé

Le statut des mots-clés de rapport se fait simplement en utilisant des exceptions. Si
une méthode exécutée déclenche une exception, le statut du mot clé est FAIL, et s'il
retourne normalement, le statut est PASS.

Le message d'erreur affiché dans les journaux, les rapports et la console est créé à
partir du type d'exception et de son message. Avec des exceptions génériques (par
exemple, AssertionError, Exceptionet RuntimeError), seul le message d'exception
est utilisé, et avec les autres, le message est créé dans le format ExceptionType:
Actual message.

À partir de la version 2.8.2 de Robot Framework, il est possible d’éviter d’ajouter

le type d’exception comme préfixe au message d’échec, même avec des exceptions
non génériques. Cela se fait en ajoutant
un ROBOT_SUPPRESS_NAMEattribut spécial avec une valeur Trueà votre exception.

Python:
class MyError ( RuntimeError ):
ROBOT_SUPPRESS_NAME = True

Java:
la classe publique MyError étend RuntimeException {
public static final boolean ROBOT_SUPPRESS_NAME = true ;
}

Dans tous les cas, il est important pour les utilisateurs que le message d’exception
soit aussi informatif que possible.

HTML dans les messages d'erreur

À partir de Robot Framework 2.8, il est également possible d'avoir des messages
d'erreur au format HTML en démarrant le message avec le texte *HTML*:
augmenter AssertionError ( "* HTML * <a href='robotframework.org'> cadre
Robot </a> rulez !!" )

Cette méthode peut être utilisée à la fois pour générer une exception dans une
bibliothèque, comme dans l'exemple ci-dessus, et lorsque les utilisateurs fournissent un
message d'erreur dans les données de test .

Couper les longs messages automatiquement

Si le message d'erreur dépasse 40 lignes, il sera automatiquement coupé du milieu

pour éviter que les rapports deviennent trop longs et difficiles à lire. Le message
d'erreur complet est toujours affiché dans le message de journal du mot clé en
échec.

Tracebacks

La trace de l'exception est également consignée au DEBUG niveau du journal . Ces

messages ne sont pas visibles dans les fichiers journaux par défaut car ils sont très
rarement intéressants pour les utilisateurs normaux. Lors du développement de
bibliothèques, il est souvent recommandé d’exécuter des tests avec --loglevel
DEBUG.

Arrêt de l'exécution du test

Il est possible d’échouer un test élémentaire pour que l’ensemble de l’exécution du test
soit arrêté . Cela se fait simplement en ayant
un ROBOT_EXIT_ON_FAILURE attribut spécial avec une Truevaleur définie sur
l'exception déclenchée par le mot clé. Ceci est illustré dans les exemples ci-
dessous.

Python:
class MyFatalError ( RuntimeError ):
ROBOT_EXIT_ON_FAILURE = True

Java:
la classe publique MyFatalError étend RuntimeException {
public static final boolean ROBOT_EXIT_ON_FAILURE = true ;
}

Poursuite de l'exécution des tests malgré les échecs

Il est possible de continuer l'exécution du test même en cas de panne . La manière de
signaler ceci à partir des bibliothèques de test consiste à ajouter
un ROBOT_CONTINUE_ON_FAILUREattribut spécialavec une Truevaleur à l'exception
utilisée pour communiquer l'échec. Ceci est démontré par les exemples ci-dessous.

Python:
classe MyContinuableError ( RuntimeError ):
ROBOT_CONTINUE_ON_FAILURE = True

Java:
la classe publique MyContinuableError étend RuntimeException {
public static final boolean ROBOT_CONTINUE_ON_FAILURE = true ;
}

Informations de journalisation
Les messages d'exception ne sont pas le seul moyen de fournir des informations
aux utilisateurs. De plus, les méthodes peuvent également envoyer des messages
aux fichiers journaux simplement en écrivant dans le flux de sortie standard (stdout)
ou dans le flux d’erreurs standard (stderr), et ils peuvent même utiliser
différents niveaux de journal . Une autre possibilité de journalisation, souvent
meilleure, consiste à utiliser les API de journalisation par programme .
Par défaut, tout ce qui est écrit par une méthode dans la sortie standard est écrit
dans le fichier journal en tant qu'entrée unique avec le niveau de
journalisation INFO. Les messages écrits dans l'erreur standard sont traités de la
même manière, mais ils sont renvoyés au stderr d'origine une fois l'exécution du
mot clé terminée. Il est donc possible d'utiliser le stderr si certains messages
doivent être visibles sur la console où les tests sont exécutés.

Utiliser les niveaux de journalisation

Pour utiliser d' autres niveaux de journal que INFO, ou pour créer plusieurs
messages, spécifiez le niveau de journalisation explicitement en intégrant le niveau
dans le message au format *LEVEL* Actual log message, où *LEVEL*doit être au
début d'une ligne et LEVELest l' un des niveaux d' enregistrement
disponibles TRACE, DEBUG, INFO, WARN, ERRORet HTML.

Erreurs et avertissements

Les messages avec ERRORou WARNlevel sont automatiquement écrits sur la console et
une section distincte Erreurs de l'exécution du test dans les fichiers journaux. Cela
rend ces messages plus visibles que d'autres et permet de les utiliser pour signaler
des problèmes importants mais non critiques aux utilisateurs.

Remarque

Dans Robot Framework 2.9, de nouvelles fonctionnalités ont été ajoutées pour ajouter
automatiquement les erreurs consignées par mots-clés dans la section Erreurs d'exécution de
test.

HTML de journalisation

Tout ce qui est normalement consigné par la bibliothèque sera converti dans un
format pouvant être représenté en toute sécurité au format HTML. Par
exemple, <b>foo</b>seront affichés dans le journal exactement comme ça et pas
comme foo . Si les bibliothèques souhaitent utiliser le formatage, les liens, les
images d'affichage, etc., elles peuvent utiliser un pseudo niveau de journalisation
spécial HTML. Robot Framework écrira ces messages directement dans le journal
avec le INFOniveau afin qu'ils puissent utiliser la syntaxe HTML de leur
choix. Notez que cette fonctionnalité doit être utilisée avec précaution car, par
exemple, une </table>balise mal placée peut endommager le fichier journal.

Lors de l'utilisation de l' API de journalisation publique , diverses méthodes de

journalisation ont des htmlattributs facultatifs pouvant être définis True pour
permettre la journalisation au format HTML.

Horodatage
Par défaut, les messages enregistrés via la sortie standard ou les flux d'erreur
obtiennent leurs horodatages à la fin du mot clé exécuté. Cela signifie que les
horodatages ne sont pas précis et que les problèmes de débogage, en particulier
avec les mots-clés plus longs, peuvent être problématiques.

Les mots-clés ont la possibilité d'ajouter un horodatage précis aux messages qu'ils
enregistrent en cas de besoin. L’horodatage doit être donné en millisecondes depuis
l’ époque Unix et il doit être placé après le niveau de journal séparé par un deux-
points:
* INFO: 1308435758660 * Message avec horodatage
* HTML: 1308435758661 * Message <b> HTML </ b> avec horodatage

Comme illustré par les exemples ci-dessous, l'ajout de l'horodatage est facile à la
fois en utilisant Python et Java. Si vous utilisez Python, il est cependant encore plus
facile d'obtenir des horodatages précis à l'aide des API de journalisation
programmatiques . Un grand avantage de l'ajout explicite d'horodatage est que cette
approche fonctionne également avec l' interface de la bibliothèque distante .

Python:
temps d' importation

def example_keyword ():

print '* INFO: % d * Message avec horodatage' % ( time . time () *
1000 )

Java:
public void exampleKeyword () {
Système . out . println ( "* INFO:" + System . currentTimeMillis ()
+ "* Message avec horodatage" );
}

Enregistrement sur la console

Si les bibliothèques doivent écrire quelque chose sur la console, elles ont plusieurs
options. Comme indiqué précédemment, les avertissements et tous les messages
écrits dans le flux d'erreurs standard sont écrits à la fois dans le fichier journal et
dans la console. Ces deux options sont limitées par le fait que les messages ne
parviennent à la console qu'après la fin du mot clé en cours d'exécution. Un
avantage est que ces approches fonctionnent à la fois avec les bibliothèques basées
sur Python et Java.

Une autre option, uniquement disponible avec Python, consiste à écrire des
messages vers sys.__stdout__ou sys.__stderr__. Lorsque vous utilisez cette
approche, les messages sont écrits sur la console immédiatement et ne sont pas
écrits dans le fichier journal:
import sys

def my_keyword ( arg ):

sys . __stdout__ . write ( 'Got arg % s \ n ' % arg )

La dernière option utilise l' API de journalisation publique :

à partir robot.api importation enregistreur

def log_to_console ( arg ):

logger . console ( 'Got arg % s ' % arg )

def log_to_console_and_log_file ( arg ):

logger . info ( 'Got arg % s ' % arg , also_console = True )

Exemple de journalisation

Dans la plupart des cas, le INFOniveau est adéquat. Les niveaux

inférieurs, DEBUGet TRACE, sont utiles pour écrire des informations de débogage. Ces
messages ne sont normalement pas affichés, mais ils peuvent faciliter le débogage
des problèmes éventuels dans la bibliothèque elle-
même. Le niveau WARNou ERRORpeut être utilisé pour rendre les messages plus
visibles et HTMLest utile si un formatage est nécessaire.

Les exemples suivants expliquent le fonctionnement de la journalisation à

différents niveaux. Les programmeurs Java doivent considérer le code print
'message' comme une signification de
pseudocode System.out.println("message");.
imprimer 'Bonjour de la bibliothèque'
print '* WARN * Avertissement d'une bibliothèque.'
print '* ERROR * Quelque chose d'inattendu se produit qui pourrait
indiquer un problème dans le test.'
print '* INFO * Bonjour à nouveau!'
imprimer 'Cela fera partie du message précédent.'
print '* INFO * Ceci est un nouveau message.'
print '* INFO * Ceci est <b> texte normal </ b>.'
print '* HTML * Ceci est <b> gras </ b>.'
imprimer '* HTML * <a href="http://robotframework.org"> Framework du robot
</a>'

16: 18: INFO Bonjour de la bibliothèque.

42.123

16: 18: PRÉVENIR Avertissement d'une bibliothèque.

42.123

16: 18: ERREUR Quelque chose d'inattendu se produit qui peut indiq
42.123 problème dans le test.
 16: 18: INFO Bonjour encore!
42.123 Cela fera partie du message précédent.

16: 18: INFO Ceci est un nouveau message.

42.123

16: 18: INFO C'est <b> texte normal </ b>.

42.123

16: 18: INFO C'est gras .

42.123

16: 18: INFO Cadre robot

42.123

API de journalisation programmatique

Les API programmatiques offrent un moyen plus simple de consigner les
informations que d'utiliser les flux de sortie et d'erreur standard. Actuellement, ces
interfaces ne sont disponibles que pour les bibliothèques de tests des bases Python.

API de journalisation publique

Robot Framework dispose d'une API de journalisation basée sur Python pour écrire
des messages dans le fichier journal et sur la console. Les bibliothèques de test
peuvent utiliser cette API logger.info('My message')au lieu de se connecter via la
sortie standard, par exemple print '*INFO* My message'. En plus d'une interface de
programmation beaucoup plus propre à utiliser, cette API présente l'avantage que
les messages de journalisation ont des horodatages précis .

L'API de journalisation publique est entièrement documentée dans le cadre de la

documentation de l'API à l' adresse https://robot-framework.readthedocs.org . Voici un
exemple d'utilisation simple:
à partir robot.api importation enregistreur

def my_keyword ( arg ):

logger . debug ( 'Argument % s ' % arg )
Do_something ()
enregistreur . info ( '<i> Cet </ i> est un exemple ennuyeux' , html =
True )
enregistreur . console ( 'Bonjour, console!' )

Une limitation évidente est que les bibliothèques de test utilisant cette API de
journalisation dépendent de Robot Framework. Avant la version 2.8.7 Robot devait
également être en cours d'exécution pour que la journalisation fonctionne. À partir
de Robot Framework 2.8.7, si les robots ne sont pas en cours d’exécution, les
messages sont redirigés automatiquement vers le module de journalisation standard
de Python .

Utiliser le loggingmodule standard de Python

En plus de la nouvelle API de journalisation publique , Robot Framework offre une

prise en charge intégrée du module de journalisation standard de Python . Cela
fonctionne de sorte que tous les messages reçus par l'enregistreur racine du module
sont automatiquement propagés au fichier journal de Robot Framework. En outre,
cette API produit des messages de journal avec des horodatagesprécis , mais la
journalisation des messages HTML ou l'écriture de messages sur la console n'est
pas prise en charge. Un grand avantage, illustré également par l'exemple simple ci-
dessous, est que l'utilisation de cette API de journalisation ne crée aucune
dépendance pour Robot Framework.
importation de journaux

def my_keyword ( arg ):

journalisation . debug ( 'Argument % s ' % arg )
do_something ()
journalisation . info ( 'Ceci est un exemple ennuyeux' )

Le loggingmodule a des niveaux de journalisation légèrement différents de ceux de

Robot Framework. Ses niveaux DEBUG, INFO, WARNINGet ERRORsont directement mis
en correspondance avec les niveaux de log-cadre de robot correspondant,
et CRITICAL est mis en correspondance ERROR. Les niveaux de journalisation
personnalisés sont mappés au niveau standard le plus proche du niveau
personnalisé. Par exemple, un niveau entre INFOet WARNINGest mappé au INFOniveau
de la structure de robot .

Enregistrement lors de l'initialisation de la bibliothèque

Les bibliothèques peuvent également se connecter lors de l'importation et de
l'initialisation de la bibliothèque de tests. Ces messages ne figurent pas dans
le fichier journal comme les messages du journal normal, mais sont plutôt écrits dans
le syslog . Cela permet de consigner toute sorte d'informations de débogage utiles
sur l'initialisation de la bibliothèque. Les messages consignés à l'aide
des niveaux WARNou ERRORsont également visibles dans la section Erreurs
d'exécution du test du fichier journal.

Enregistre pendant l'importation et l' initialisation est possible à la fois en utilisant

les courants de sortie standard et d' erreur et les API de journalisation de programme . Les
deux sont démontrés ci-dessous.

Enregistrement de la bibliothèque Java via stdout lors de l'initialisation:

classe publique LoggingDuringInitialization {
 public LoggingDuringInitialization () {
Système . out . println ( "* INFO * Initializing library" );
}

mot-clé vide public () { // ... } }

Enregistrement de la bibliothèque Python à l'aide de l'API de journalisation lors de

l'importation:
à partir robot.api importation enregistreur

enregistreur . debug ( "Importing library" )

mot-clé def ():

# ...

Remarque

Si vous enregistrez quelque chose lors de l'initialisation, c'est-à-dire en Python __init__ou

dans un constructeur Java, les messages peuvent être consignés plusieurs fois en fonction de
l' étendue de la bibliothèque de tests .

Valeurs de retour
La dernière méthode utilisée par les mots-clés pour communiquer avec la structure
principale consiste à renvoyer les informations extraites du système testé ou
générées par d'autres moyens. Les valeurs renvoyées peuvent être affectées à des
variables dans les données de test, puis utilisées comme entrées pour d'autres mots-
clés, même à partir de différentes bibliothèques de tests.

Les valeurs sont renvoyées à l'aide de l' returninstruction provenant des méthodes
Python et Java. Normalement, une valeur est affectée dans une variable scalaire ,
comme illustré dans l'exemple ci-dessous. Cet exemple montre également qu'il est
possible de renvoyer des objets et d'utiliser la syntaxe de variable étendue pour
accéder aux attributs d'objet.
from mymodule import MyObject

def return_string ():

retourne "Hello, world!"

def return_object ( name ):

retourne MyObject ( name )
*** Cas de test ***
Renvoyer une valeur
$ { string } = Retourne la chaîne
Devrait être égal $ { string } Bonjour tout le monde!
$ { object } = Retourne le robot objet
Devrait être égal à $ { object.name } Robot
Les mots-clés peuvent également renvoyer des valeurs afin de pouvoir les affecter
simultanément à plusieurs variables scalaires , à une variable de liste ou à des variables
scalaires et à une variable de liste. Toutes ces utilisations exigent que les valeurs
renvoyées soient des listes ou des tuples Python ou des tableaux, des listes ou des
itérateurs Java.
def return_two_values ():
retourne 'first value' , 'second value'

def return_multiple_values ():

return [ 'a' , 'list' , 'of' , 'strings' ]
*** Cas de test ***
Renvoyer plusieurs valeurs
$ { var1 } $ { var2 } = Renvoie deux valeurs
Devrait être égal à $ { var1 } première valeur
Devrait être égal à $ { var2 } deuxième valeur
@ { list } = Renvoie deux valeurs
Devrait être égal à @ { list } [ 0 ] première valeur
Devrait être égal à @ { list } [ 1 ] deuxième valeur
$ { s1 } $ { s2 } @ { li } = Retourne plusieurs valeurs
Devrait être égal à $ { s1 } $ { s2 } une liste
Devrait être égal à @ { li } [ 0 ] @ { li } [ 1 ] des chaînes

Communication lors de l'utilisation de threads

Si une bibliothèque utilise des threads, elle ne devrait généralement communiquer
avec le framework qu'à partir du thread principal. Par exemple, si un thread de
travail ne parvient pas à signaler ou à consigner quelque chose, il doit d'abord
transmettre l'information au thread principal, qui peut alors utiliser des exceptions
ou d'autres mécanismes expliqués dans cette section pour communiquer avec le
framework.

Ceci est particulièrement important lorsque les threads sont exécutés en arrière-plan
alors que d'autres mots-clés sont en cours d'exécution. Les résultats de la
communication avec le framework dans ce cas sont indéfinis et peuvent, dans le
pire des cas, provoquer un crash ou un fichier de sortie corrompu. Si un mot clé
démarre quelque chose en arrière-plan, il doit y avoir un autre mot clé qui vérifie le
statut du thread de travail et les rapports recueillent des informations en
conséquence.

Les messages consignés par des threads non principaux à l'aide des méthodes de
journalisation normales des API de journalisation par programme sont ignorés en
silence.

Il existe également un projet robotbackgroundloggerBackgroundLogger séparé , avec

une API similaire à celle standard . Les méthodes de journalisation normales
ignoreront les messages d'un thread autre que le thread principal,
mais enregistreront les messages d'arrière-plan afin qu'ils puissent être enregistrés
ultérieurement dans le journal de Robot.robot.api.loggerBackgroundLogger
4.1.5 Distribution des bibliothèques de test
Documentation des bibliothèques
Une bibliothèque de test sans documentation sur les mots-clés qu'elle contient et
sur ce que font ces mots-clés est plutôt inutile. Pour faciliter la maintenance, il est
fortement recommandé que la documentation de la bibliothèque soit incluse dans le
code source et générée à partir de celui-ci. En gros, cela signifie
utiliser docstrings avec Python et Javadoc avec Java, comme dans les exemples ci-
dessous.
class MyLibrary :
"" Ceci est un exemple de bibliothèque avec de la documentation. "" "

def keyword_with_short_documentation ( self , argument ):

"" "Ce mot clé n'a qu'une courte documentation" ""
pass

def keyword_with_longer_documentation ( self ):

"" "La première ligne de la documentation est ici.

Une documentation plus longue continue ici et peut contenir

plusieurs lignes ou paragraphes.
"" "
passe
/ **
* Ceci est un exemple de bibliothèque avec de la documentation.
* /
classe publique MyLibrary {

/ **
* Ce mot clé n'a qu'une courte documentation
* /
public void keywordWithShortDocumentation ( argument de chaîne ) { }

/ **
* La première ligne de la documentation est ici.
*
* Une documentation plus longue continue ici et peut contenir
* plusieurs lignes ou paragraphes.
* /
public void keywordWithLongerDocumentation () {
}

Python et Java ont tous deux des outils pour créer une documentation API d'une
bibliothèque documentée comme ci-dessus. Cependant, les sorties de ces outils
peuvent être légèrement techniques pour certains utilisateurs. Une autre alternative
consiste à utiliser le propre outil de documentation de Robot
Framework, Libdoc . Cet outil peut créer une documentation de bibliothèque à partir
des bibliothèques Python et Java à l'aide de l'API de bibliothèque statique, comme
celles ci-dessus, mais il gère également les bibliothèques utilisant l' API de
bibliothèque dynamique et l' API de bibliothèque hybride .

La première ligne de la documentation d'un mot-clé est utilisée dans un but

spécifique et devrait contenir une courte description générale du mot-clé. Il est
utilisé comme une courte documentation , par exemple comme une info - bulle ,
par Libdoc et également dans les journaux de test. Cependant, ce dernier ne
fonctionne pas avec les bibliothèques Java utilisant l'API statique, car leurs
documentations sont perdues dans la compilation et ne sont pas disponibles au
moment de l'exécution.

Par défaut, la documentation est considérée comme conforme aux règles

de formatage de la documentation de Robot Framework . Ce format simple permet
d'utiliser des styles souvent utilisés tels *bold*que _italic_, et , des tables, des
listes, des liens, etc. À partir de Robot Framework 2.7.5, il est possible d'utiliser
également des formats HTML, texte brut et reStructuredText . Reportez-vous à la
section Spécification du format de documentation pour savoir comment définir le format
dans le code source de la bibliothèque et dans le chapitre Libdoc pour plus
d'informations sur les formats en général.

Remarque

Si vous souhaitez utiliser des caractères non-ASCII dans la documentation des bibliothèques
Python, vous devez soit utiliser UTF-8 comme encodage de votre code source, soit créer des
docstrings comme Unicode.

Test des bibliothèques

Toute bibliothèque de test non triviale doit être testée en profondeur pour éviter les
bogues. Bien entendu, ce test devrait être automatisé pour faciliter la réexécution
des tests lorsque les bibliothèques sont modifiées.

Python et Java ont tous deux d'excellents outils de test unitaire, et ils fonctionnent
très bien pour tester les bibliothèques. Il n'y a pas de différences majeures dans leur
utilisation à cette fin par rapport à leur utilisation pour d'autres tests. Les
développeurs familiers avec ces outils n’ont pas besoin d’apprendre quelque chose
de nouveau, et les développeurs qui ne les connaissent pas devraient tout de même
les apprendre.

Il est également facile d’utiliser Robot Framework lui-même pour tester les
bibliothèques et, de cette manière, disposer de tests d’acceptation de bout en
bout. Il existe de nombreux mots-clés utiles dans la bibliothèque BuiltIn à cet
effet. Il convient de mentionner spécifiquement Run Error And Expect Error , qui
est utile pour tester que les mots-clés signalent correctement les erreurs.
L'utilisation d'une approche de test au niveau de l'unité ou de l'acceptation dépend
du contexte. S'il est nécessaire de simuler le système en cours de test, il est souvent
plus facile au niveau de l'unité. D'autre part, les tests d'acceptation garantissent que
les mots-clés fonctionnent via Robot Framework. Si vous ne pouvez pas décider,
bien sûr, il est possible d'utiliser les deux approches.

Bibliothèques d'emballage
Une fois la bibliothèque implémentée, documentée et testée, elle doit toujours être
distribuée aux utilisateurs. Avec des bibliothèques simples constituées d'un seul
fichier, il suffit souvent de demander aux utilisateurs de copier ce fichier quelque
part et de définir le chemin de recherche du module en conséquence. Des bibliothèques
plus complexes devraient être empaquetées pour faciliter l'installation.

Les bibliothèques étant un code de programmation normal, elles peuvent être

empaquetées à l’aide d’outils d’emballage normaux. Avec Python, les options
incluent les distutils , contenus dans la bibliothèque standard de Python, et les
nouveaux setuptools . Un avantage de ces outils est que les modules de bibliothèque
sont installés dans un emplacement qui se trouve automatiquement dans le chemin
de recherche du module .

Lors de l'utilisation de Java, il est naturel de conditionner les bibliothèques dans

une archive JAR. Le package JAR doit être placé dans le chemin de
recherche du module avant d'exécuter des tests, mais il est facile de créer un script de
démarrage qui le fait automatiquement.

Mots clés dépréciés

Il est parfois nécessaire de remplacer les mots-clés existants par de nouveaux mots-
clés ou de les supprimer complètement. Le simple fait d'informer les utilisateurs du
changement ne suffit pas toujours, et il est plus efficace d'obtenir des
avertissements à l'exécution. Pour ce faire, Robot Framework peut marquer des
mots-clés obsolètes . Cela facilite la recherche d'anciens mots-clés à partir des
données de test et les supprime ou les remplace.

Les mots-clés peuvent être désapprouvés en démarrant leur documentation avec du

texte *DEPRECATED, en respectant la casse et en fermant *également la première ligne
de la documentation. Par exemple, *DEPRECATED*, *DEPRECATED.*et *DEPRECATED in
version 1.5.*sont tous les marqueurs valides.

Lorsqu'un mot clé obsolète est exécuté, un avertissement de dépréciation est

consigné et l'avertissement est également affiché dans la console et dans la section
Erreurs d'exécution de l'exécution des fichiers journaux . L'avertissement de dépréciation
commence par le texte Keyword '<name>' is deprecated.et contient le reste de
la courte documentation après le marqueur de dépréciation, le cas échéant, après. Par
exemple, si le mot clé suivant est exécuté, il y aura un avertissement comme
indiqué ci-dessous dans le fichier journal.
def example_keyword ( argument ):
"" "* DEPRECATED !! * Utilisez plutôt le mot clé` Other Keyword`.

Ce mot-clé fait quelque chose pour donner `` argument`` et renvoie des

résultats.
"" "
retourne quelque chose ( argument )

20080911 PRÉVENIR Le mot clé "SomeLibrary.Example Keyword" est

16: 00: obsolète. Utilisez le mot-clé `Autre mot-clé` à la
22.650

Ce système de dépréciation fonctionne avec la plupart des bibliothèques de tests et

avec les mots-clés des utilisateurs . La seule exception concerne les mots clés
implémentés dans une bibliothèque de tests Java qui utilise l' interface de bibliothèque
statique car leur documentation n'est pas disponible au moment de l'exécution. Avec
de tels mots-clés, il est possible d'utiliser des mots-clés utilisateur comme wrappers
et de les déconseiller.

Remarque

Avant Robot Framework 2.9, la documentation doit commencer *DEPRECATED*exactement

sans aucun contenu supplémentaire avant la fermeture *.

4.1.6 API de bibliothèque dynamique

L'API dynamique est dans la plupart des cas similaire à l'API statique. Par exemple,
signaler le statut du mot clé, se connecter et renvoyer des valeurs fonctionne
exactement de la même manière. Plus important encore, l'importation de
bibliothèques dynamiques et l'utilisation de leurs mots-clés ne diffèrent pas de
celles d'autres bibliothèques. En d'autres termes, les utilisateurs n'ont pas besoin de
savoir quelles API utilisent leurs bibliothèques.

Seules les différences entre les bibliothèques statiques et dynamiques sont la façon
dont Robot Framework découvre les mots-clés qu'une bibliothèque implémente, les
arguments et la documentation de ces mots-clés, et comment les mots-clés sont
réellement exécutés. Avec l'API statique, tout cela se fait en utilisant la réflexion (à
l'exception de la documentation des bibliothèques Java), mais les bibliothèques
dynamiques ont des méthodes spéciales utilisées à ces fins.

L'un des avantages de l'API dynamique est que vous avez plus de flexibilité dans
l'organisation de votre bibliothèque. Avec l'API statique, vous devez disposer de
tous les mots clés dans une classe ou un module, tandis qu'avec l'API dynamique,
vous pouvez, par exemple, implémenter chaque mot clé en tant que classe
distincte. Ce cas d'utilisation n'est pas si important avec Python, car ses capacités
dynamiques et son héritage multiple offrent déjà une grande flexibilité, et il est
également possible d'utiliser l' API de la bibliothèque hybride .

Un autre cas d'utilisation majeur de l'API dynamique consiste à implémenter une

bibliothèque afin qu'elle fonctionne en tant que proxy pour une bibliothèque réelle
pouvant s'exécuter sur un autre processus ou même sur une autre machine. Ce type
de bibliothèque de proxy peut être très mince, et comme les noms de mots-clés et
toutes les autres informations sont obtenus dynamiquement, il n'est pas nécessaire
de mettre à jour le proxy lorsque de nouveaux mots-clés sont ajoutés à la
bibliothèque réelle.

Cette section explique comment l'API dynamique fonctionne entre Robot

Framework et les bibliothèques dynamiques. Peu importe pour Robot Framework
comment ces bibliothèques sont réellement implémentées (par exemple, comment
les appels à la run_keywordméthode sont mappés à une implémentation de mot clé
correcte), de nombreuses approches différentes sont possibles. Cependant, si vous
utilisez Java, vous souhaiterez peut-être examiner le projet JavaLibCore avant
d’implémenter votre propre système. Cette collection d'outils réutilisables prend en
charge plusieurs manières de créer des mots-clés, et il est probable qu'elle dispose
déjà d'un mécanisme qui répond à vos besoins. Les utilisateurs Python peuvent
également trouver utile le projet PythonLibCoresimilaire .

Obtenir des noms de mots clés

Les bibliothèques dynamiques indiquent quels mots-clés elles implémentent avec
la get_keyword_namesméthode. La méthode a également
l'alias getKeywordNamesrecommandé lors de l'utilisation de Java. Cette méthode ne
peut prendre aucun argument et doit renvoyer une liste ou un tableau de chaînes
contenant les noms des mots-clés que la bibliothèque implémente.

Si les noms de mots-clés renvoyés contiennent plusieurs mots, ils peuvent être
renvoyés séparés par des espaces ou des traits de soulignement, ou au format
camelCase. Par exemple, ['first keyword', 'second
keyword'], ['first_keyword', 'second_keyword']et ['firstKeyword',
'secondKeyword']seraient tous mis en correspondance aux mots - clés premier mot
clé et des mots - clés .

Les bibliothèques dynamiques doivent toujours avoir cette méthode. S'il est
manquant ou si l'appel échoue pour une raison quelconque, la bibliothèque est
considérée comme une bibliothèque statique.

Marquage des méthodes à exposer en tant que mots clés

Si une bibliothèque dynamique doit contenir à la fois des méthodes destinées à être
des mots-clés et des méthodes destinées à être des méthodes d'assistance privées, il
peut être judicieux de marquer les méthodes de mots-clés en tant que telles pour
faciliter leur
implémentation get_keyword_names. Le robot.api.deco.keyworddécorateur permet
de le faire facilement car il crée un robot_nameattribut personnalisé sur la méthode
décorée. Cela permet de générer la liste des mots clés simplement en vérifiant
l' robot_name attribut sur chaque méthode de la bibliothèque
pendant get_keyword_names. Voir Utilisation d'un nom de mot clé personnalisé pour plus
d'informations sur ce décorateur.
à partir du mot-clé d' importation robot.api.deco

class DynamicExample :

def get_keyword_names ( self ):

retourne [ nom pour le nom dans dir ( self ) si hasattr (
getattr ( self , name ), 'nom_ robot' )]

def helper_method ( self ):

# ...

@keyword
def keyword_method ( self ):
# ...

Mots clés en cours d'exécution

Les bibliothèques dynamiques ont
une méthode spéciale run_keyword(alias runKeyword) pour exécuter leurs mots-
clés. Lorsqu'un mot clé d'une bibliothèque dynamique est utilisé dans les données
de test, Robot Framework utilise la run_keywordméthode de la bibliothèque pour
l'exécuter. Cette méthode prend deux ou trois arguments. Le premier argument est
une chaîne contenant le nom du mot-clé à exécuter dans le même format que celui
renvoyé par get_keyword_names. Le deuxième argument est une liste ou un tableau
d'arguments donnés au mot-clé dans les données de test.

Le troisième argument facultatif est un dictionnaire (map in Java) qui permet à un

mot-clé gratuit des arguments ( **kwargs) transmis au mot-clé. Voir les arguments de
mots-clés gratuits avec lasection des bibliothèques dynamiques pour plus de détails sur
l'utilisation de kwargs avec les bibliothèques de tests dynamiques.

Après avoir obtenu le nom du mot-clé et les arguments, la bibliothèque peut

exécuter le mot-clé librement, mais il doit utiliser le même mécanisme pour
communiquer avec l'infrastructure que les bibliothèques statiques. Cela signifie
qu'il faut utiliser des exceptions pour signaler l'état des mots-clés, se connecter en
écrivant sur la sortie standard ou en utilisant les API de journalisation fournies, et
utiliser l'instruction return run_keywordpour renvoyer quelque chose.
Chaque bibliothèque dynamique doit avoir
les deux get_keyword_nameset run_keywordméthodes , mais reste des méthodes de
l'API dynamique sont en option. L'exemple ci-dessous montre une bibliothèque
dynamique, bien que triviale, implémentée dans Python.
class DynamicExample :

def get_keyword_names ( self ):

return [ 'premier mot clé' , 'second mot clé' ]

def run_keyword ( self , name , args ):

print "Mot clé en cours d'exécution ' % s ' avec les arguments % s
." % ( nom , args )

Obtenir des arguments de mots clés

Si une bibliothèque dynamique implémente uniquement
les méthodes get_keyword_namesand run_keyword, Robot Framework ne dispose
d'aucune information sur les arguments dont les mots clés implémentés ont
besoin. Par exemple, le mot - clé First et le mot - clé Second dans l'exemple ci-
dessus peuvent être utilisés avec un nombre quelconque d'arguments. Ceci est
problématique, car la plupart des mots-clés réels attendent un certain nombre de
mots-clés et, dans ces circonstances, ils doivent vérifier le nombre d'arguments eux-
mêmes.

Les bibliothèques dynamiques peuvent indiquer à Robot Framework les arguments

attendus par les mots-clés en utilisant
la méthode get_keyword_arguments (alias getKeywordArguments). Cette méthode
prend le nom d'un mot clé en tant qu'argument et renvoie une liste ou un tableau de
chaînes contenant les arguments acceptés par ce mot clé.

De même que les mots-clés statiques, les mots-clés dynamiques peuvent nécessiter
un nombre quelconque d'arguments, avoir des valeurs par défaut et accepter un
nombre variable d'arguments et des arguments de mots-clés gratuits. La syntaxe
pour représenter toutes ces différentes variables est expliquée dans le tableau
suivant. Notez que les exemples utilisent la syntaxe Python pour les listes, mais les
développeurs Java doivent utiliser des listes Java ou des tableaux à la place.

Représenter différents arguments avec get_keyword_arguments

Arguments Comment représenter Exemples Limites

attendus (min /
max)
[] 0/0
Aucun argument Liste vide
['one_argument'] 1/1
Un ou plusieurs Liste de chaînes contenant des noms
arguments d'argument. ['a1', 'a2', 3/3
'a3']
 Représenter différents arguments avec get_keyword_arguments

Arguments Comment représenter Exemples Limites

attendus (min /
max)
['arg=default 0/1
Valeurs par défaut Les valeurs par défaut sont séparées
value']
pour les arguments des noms par =. Les valeurs par 1/3
défaut sont toujours considérées ['a', 'b=1',
'c=2']
comme des chaînes.
['*varargs'] 0 / tout
Nombre variable Le dernier argument (ou le dernier
d'arguments avec kwargs) a * avant son nom. ['a', 'b=42', 1 / tout
(varargs) '*rest']

['**kwargs'] 0/0
Arguments de Les derniers arguments ont **avant
mots clés gratuits son nom. ['a', 'b=42', 1/2
(kwargs) '**kws']
0 / tout
['*varargs',
'**kwargs']

Lorsqu'elle get_keyword_argumentsest utilisée, Robot Framework calcule

automatiquement le nombre d'arguments positionnels requis par le mot clé et prend
en charge les arguments de mots clés gratuits ou non. Si un mot-clé est utilisé avec
des arguments non valides, une erreur se produit et run_keywordn'est même pas
appelée.

Les noms d'argument réels et les valeurs par défaut renvoyées sont également
importants. Ils sont nécessaires pour le support des arguments nommés et l' outil Libdoc
en a besoin pour pouvoir créer une documentation de bibliothèque significative.

Si get_keyword_argumentsest manquant ou renvoie Noneou nullpour un certain mot-

clé, ce mot-clé obtient une spécification d'argument acceptant tous les
arguments. Cette spécification d'argument automatique est soit [*varargs,
**kwargs]ou [*varargs], selon prend en run_keyword charge kwargs en ayant trois
arguments ou non.

Obtenir des mots-clés

À partir de Robot Framework 3.0.2, les bibliothèques dynamiques peuvent signaler
les balises de mots-clés en utilisant la get_keyword_tagsméthode
(alias getKeywordTags). Il obtient un nom de mot-clé en tant qu'argument et doit
renvoyer les balises correspondantes sous la forme d'une liste de chaînes.

Il est également possible de spécifier des balises sur la dernière ligne de la

documentation renvoyée par la get_keyword_documentationméthode décrite ci-
dessous. Cela nécessite de démarrer la dernière ligne avec Tags:et lister les balises
après celle-ci Tags: first tag, second, third. Cette approche fonctionne
également avec les versions de Robot Framework antérieures à 3.0.2.

Pointe

La get_keyword_tagsméthode est garantie d'être appelée avant

la get_keyword_documentationméthode. Cela facilite l'intégration de balises dans la
documentation uniquement si la get_keyword_tags méthode n'est pas appelée.

Obtenir de la documentation sur les mots clés

Si les bibliothèques dynamiques veulent fournir une documentation sur les mots
clés, elles peuvent implémenter la get_keyword_documentationméthode
(alias getKeywordDocumentation). Il prend un nom de mot-clé en tant qu'argument
et, comme l'indique le nom de la méthode, renvoie sa documentation sous forme de
chaîne.

La documentation renvoyée est utilisée de la même manière que la chaîne de

documentation du mot-clé avec les bibliothèques statiques implémentées avec
Python. Le principal cas d'utilisation consiste à obtenir des documentations de
mots-clés dans une documentation de bibliothèque générée par Libdoc . De plus, la
première ligne de la documentation (jusqu'au premier \n) est affichée dans les
journaux de test.

Obtenir la documentation générale de la bibliothèque

La get_keyword_documentationméthode peut également être utilisée pour spécifier
la documentation globale de la bibliothèque. Cette documentation n'est pas utilisée
lors de l'exécution des tests, mais elle peut améliorer considérablement la
documentation générée par Libdoc .

Les bibliothèques dynamiques peuvent fournir à la fois la documentation générale

de la bibliothèque et la documentation relative à l'utilisation de la bibliothèque. Le
premier est obtenu en appelant get_keyword_documentationavec une valeur
spéciale __intro__, et le second utilise la valeur __init__. La manière dont la
documentation est présentée est mieux testée avec Libdoc dans la pratique.

Les bibliothèques dynamiques basées sur Python peuvent également spécifier la

documentation de la bibliothèque générale directement dans le code en tant que
documentation de la classe de bibliothèque et de sa __init__méthode. Si une
documentation non vide est obtenue à la fois directement à partir du code et de
la get_keyword_documentationméthode, cette dernière a la priorité.

Syntaxe des arguments nommés avec bibliothèques dynamiques

À partir de Robot Framework 2.8, l'API de bibliothèque dynamique prend
également en charge la syntaxe d'argument nommé . L'utilisation de la syntaxe
fonctionne en fonction des noms d'argument et des valeurs par défaut obtenues de la
bibliothèque à l'aide de la get_keyword_argumentsméthode.

Dans la plupart des cas, la syntaxe des arguments nommés fonctionne avec des
mots-clés dynamiques exactement comme elle fonctionne avec tout autre mot-clé
qui la prend en charge. Le seul cas particulier est celui où un mot-clé a plusieurs
arguments avec des valeurs par défaut, et seuls certains de ces derniers sont
donnés. Dans ce cas, la structure remplit les arguments facultatifs ignorés en
fonction des valeurs par défaut renvoyées par la get_keyword_argumentsméthode.

L'utilisation de la syntaxe de l'argument nommé avec les bibliothèques dynamiques

est illustrée par les exemples suivants. Tous les exemples utilisent un mot
clé Dynamic qui a été spécifié pour avoir la spécification d'argument [arg1,
arg2=xxx, arg3=yyy]. Le commentaire montre les arguments avec lesquels le mot-
clé est réellement appelé.
*** Cas de test ***
Seulement positionnel
Dynamique a # [a] Dynamique a b # [a, b] Dynamique a b c # [a, b, c]

Nommé
Dynamique a arg2 = b # [a, b] Dynamique a b arg3 = c # [a, b, c]
Dynamique a arg2 = b arg3 = c # [a, b, c] Dynamique arg1 = a arg2 = b arg3
= c # [a, b, c]

Remplir sauté
Dynamique un arg3 = c # [a, xxx, c]

Arguments de mots clés gratuits avec bibliothèques dynamiques

À partir de Robot Framework 2.8.2, les bibliothèques dynamiques peuvent
également prendre en charge les arguments de mots clés gratuits ( **kwargs). Une
condition préalable obligatoire pour ce support est que
la run_keywordméthode prenne trois arguments : le troisième aura kwargs quand ils
seront utilisés. Kwargs sont transmis au mot-clé en tant que dictionnaire (Python)
ou Map (Java).

Les arguments qu'un mot clé accepte dépendent de ce qui lui

est get_keyword_arguments retourné . Si le dernier argument commence par **, ce
mot-clé est reconnu pour accepter kwargs.
Les exemples suivants illustrent l'utilisation de la syntaxe d'argument de mot clé
libre avec les bibliothèques dynamiques. Tous les exemples utilisent un mot
clé Dynamic qui a été spécifié pour avoir la spécification d'argument [arg1=xxx,
arg2=yyy, **kwargs]. Le commentaire montre les arguments avec lesquels le mot-
clé est réellement appelé.
*** Cas de test ***
Aucun argument
Dynamic # [], {}

Seulement positionnel
Dynamique a # [a], {} dynamique a b # [a, b], {}

Seulement kwargs
Dynamique a = 1 # [], {a: 1} Dynamique a = 1 b = 2 c = 3 # [], {a: 1,
b: 2, c: 3}

Positionnel et kwargs
Dynamique a b = 2 # [a], {b: 2} Dynamique a b = 2 c = 3 # [a], {b: 2,
c: 3}

Nommé et kwargs
Dynamique arg1 = a b = 2 # [a], {b: 2} dynamique arg2 = a b = 2 c = 3 #
[xxx, a], {b: 2, c: 3}

Résumé
Toutes les méthodes spéciales de l'API dynamique sont répertoriées dans le tableau
ci-dessous. Les noms de méthode sont répertoriés au format de soulignement, mais
leurs alias camelCase fonctionnent exactement de la même manière.

Toutes les méthodes spéciales de l'API dynamique

prénom Arguments Objectif

get_keyword_names Renvoie les noms des mots-clés
implémentés.
run_keyword name, Exécutez le mot-clé spécifié avec des
arguments, arguments donnés. kwargsest facultatif
kwargs

get_keyword_arguments name Renvoie les spécifications de l'argument

des mots-clés . Méthode optionnelle
get_keyword_documentation name Retour mots - clés et de
la bibliothèque de
documentation . Méthode optionnelle
Il est possible d'écrire une spécification d'interface formelle en Java comme ci-
dessous. Cependant, rappelez - vous que les bibliothèques ne ont pas besoin de
mettre en œuvre une interface explicite, parce que cadre robot vérifie directement
avec la réflexion si la bibliothèque a le nécessaire get_keyword_nameset
les run_keywordméthodes ou leurs alias CamelCase. De
plus,get_keyword_argumentset get_keyword_documentation sont complètement
facultatifs.
interface publique RobotFrameworkDynamicAPI {

List < String > getKeywordNames ();

Object runKeyword ( nom de chaîne , arguments de liste );

Objet runKeyword ( chaîne nom , Liste des arguments , Carte

kwargs );

List < String > getKeywordArguments ( nom de la chaîne );

String getKeywordDocumentation ( nom de chaîne );

Remarque

En plus d'utiliser List, il est possible d'utiliser aussi des tableaux

comme Object[]ou String[].

Un bon exemple d'utilisation de l'API dynamique est la bibliothèque distante de Robot

Framework .

4.1.7 API de bibliothèque hybride

L'API de la bibliothèque hybride est, comme son nom l'indique, un hybride entre
l'API statique et l'API dynamique. Tout comme avec l'API dynamique, il est
possible d'implémenter une bibliothèque utilisant l'API hybride uniquement en tant
que classe.

Obtenir des noms de mots clés

Les noms de mots clés sont obtenus exactement de la même manière qu'avec les
API dynamiques. Dans la pratique, la bibliothèque doit avoir
la méthode get_keyword_namesor getKeywordNamesrenvoyant une liste de noms de
mots-clés que la bibliothèque implémente.

Mots clés en cours d'exécution

Dans l'API hybride, il n'y a pas de run_keywordméthode pour exécuter des mots
clés. Au lieu de cela, Robot Framework utilise la réflexion pour trouver des
méthodes implémentant des mots-clés, de la même manière qu'avec l'API
statique. Une bibliothèque utilisant l'API hybride peut implémenter ces méthodes
directement ou, plus important encore, les gérer dynamiquement.

En Python, il est facile de gérer dynamiquement les méthodes manquantes avec

la __getattr__méthode. Cette méthode spéciale est probablement familière à la
plupart des programmeurs Python et ils peuvent immédiatement comprendre
l'exemple suivant. D'autres peuvent trouver plus facile de consulter le Manuel de
référence Python en premier.

de quelque part import external_keyword

classe HybridExample :

def get_keyword_names ( self ):

return [ 'my_keyword' , 'external_keyword' ]

def my_keyword ( self , arg ):

print "Mon mot-clé appelé avec ' % s '" % arg

def __getattr__ ( self , name ):

if name == 'external_keyword' :
return external_keyword
raise AttributeError ( " Attribut non existant ' % s '" % name )

Notez que __getattr__cela n'exécute pas le mot clé réel comme le run_keywordfait
l'API dynamique. Au lieu de cela, il ne renvoie qu'un objet appelable qui est ensuite
exécuté par Robot Framework.

Un autre point à noter est que Robot Framework utilise les mêmes noms que ceux
utilisés get_keyword_namespour trouver les méthodes qui les implémentent. Ainsi,
les noms des méthodes implémentées dans la classe elle-même doivent être
renvoyés au même format que celui défini. Par exemple, la bibliothèque ci-dessus
ne fonctionnerait pas correctement si elle étaitget_keyword_namesrenvoyée My
Keywordau lieu de my_keyword.

L'API hybride n'est pas très utile avec Java, car il n'est pas possible de gérer les
méthodes manquantes. Bien sûr, il est possible d'implémenter toutes les méthodes
de la classe bibliothèque, mais cela apporte peu d'avantages par rapport à l'API
statique.

Obtention des arguments et de la documentation sur les mots clés

Lorsque cette API est utilisée, Robot Framework utilise la réflexion pour
rechercher les méthodes implémentant les mots-clés, de la même manière qu'avec
l'API statique. Après avoir obtenu une référence à la méthode, celle-ci recherche les
arguments et la documentation de la même manière que lors de l'utilisation de l'API
statique. Il n'y a donc pas besoin de méthodes spéciales pour obtenir des arguments
et de la documentation, comme c'est le cas avec l'API dynamique.
Résumé
Lors de l'implémentation d'une bibliothèque de tests en Python, l'API hybride
possède les mêmes fonctionnalités dynamiques que l'API dynamique actuelle. Un
grand avantage est qu'il n'est pas nécessaire d'avoir des méthodes spéciales pour
obtenir des arguments et de la documentation sur les mots clés. Il est également
souvent pratique que les seuls mots clés dynamiques réels doivent être
manipulés __getattr__et que d'autres puissent être implémentés directement dans
la classe principale de la bibliothèque.

En raison des avantages évidents et des capacités égales, l'API hybride est dans la
plupart des cas une meilleure alternative que l'API dynamique lors de l'utilisation
de Python. Une exception notable est l'implémentation d'une bibliothèque en tant
que proxy pour une implémentation de bibliothèque réelle, car le mot clé réel doit
alors être exécuté ailleurs et le proxy ne peut que transmettre le nom du mot clé et
ses arguments.

Un bon exemple d'utilisation de l'API hybride est la bibliothèque Telnet de Robot

Framework .

4.1.8 Utilisation des modules internes de Robot

Framework
Les bibliothèques de tests implémentées avec Python peuvent utiliser les modules
internes de Robot Framework, par exemple, pour obtenir des informations sur les
tests exécutés et les paramètres utilisés. Ce puissant mécanisme de communication
avec le framework doit cependant être utilisé avec précaution, car toutes les API de
Robot Framework ne sont pas destinées à être utilisées en externe et peuvent
changer radicalement entre les différentes versions du framework.

API disponibles
À partir de Robot Framework 2.7, la documentation de l'API est hébergée séparément
sur l'excellent service Read the Docs . Si vous ne savez pas comment utiliser
certaines API ou si vous les utilisez, veuillez envoyer une question à la liste de
diffusion .

Utilisation de la bibliothèque BuiltIn

Les API les plus sûres à utiliser sont des méthodes implémentant des mots-clés
dans la bibliothèque BuiltIn . Les modifications apportées aux mots-clés sont rares
et elles sont toujours effectuées pour que l’ancien usage soit tout d’abord
déconseillé. L'une des méthodes les plus utiles est celle replace_variablesqui
permet d'accéder aux variables actuellement disponibles. L'exemple suivant montre
comment obtenir l' ${OUTPUT_DIR}une des nombreuses variables
automatiques pratiques . Il est également possible de définir de nouvelles variables à
partir de bibliothèques
utilisant set_test_variable, set_suite_variableet set_global_variable.
importation os.path à
partir de robot.libraries.BuiltIn import BuiltIn

def do_something ( argument ):

output = do_something_that_creates_a_lot_of_output ( argument )
outputdir = BuiltIn () . replace_variables ( '$ {OUTPUTDIR}' )
path = os . chemin . rejoindre ( outputdir , 'results.txt' )
f = ouvert ( chemin , 'w' )
f . écrire ( sortie )
f . Fermer()
print '* HTML * Sortie écrite dans <a href="results.txt"> results.txt
</a>'

Le seul problème avec l'utilisation de méthodes BuiltInest que toutes

les run_keywordvariantes de méthodes doivent être traitées
spécialement. Les run_keywordméthodes utilisant des méthodes doivent être
enregistrées en tant que mots clés exécutés eux - mêmes en utilisant
la register_run_keyword méthode du BuiltInmodule. La documentation de cette
méthode explique pourquoi cela doit être fait et évidemment aussi comment le
faire.

4.1.9 Extension des bibliothèques de test existantes

Cette section explique différentes méthodes pour ajouter de nouvelles
fonctionnalités aux bibliothèques de test existantes et comment les utiliser dans vos
propres bibliothèques.

Modification du code source d'origine

Si vous avez accès au code source de la bibliothèque que vous souhaitez étendre,
vous pouvez naturellement modifier directement le code source. Le plus gros
problème de cette approche est qu'il peut être difficile pour vous de mettre à jour la
bibliothèque d'origine sans affecter vos modifications. Pour les utilisateurs, il peut
également être déroutant d'utiliser une bibliothèque qui a des fonctionnalités
différentes de celles d'origine. Le reconditionnement de la bibliothèque peut
également constituer une tâche supplémentaire importante.

Cette approche fonctionne extrêmement bien si les améliorations sont génériques et

que vous prévoyez de les renvoyer aux développeurs d'origine. Si vos
modifications sont appliquées à la bibliothèque d'origine, elles sont incluses dans
les futures versions et tous les problèmes décrits ci-dessus sont atténués. Si les
modifications ne sont pas génériques ou si, pour une autre raison, vous ne pouvez
pas les renvoyer, les approches expliquées dans les sections suivantes fonctionnent
probablement mieux.

Utiliser l'héritage
Un autre moyen simple d'étendre une bibliothèque existante consiste à utiliser
l'héritage. Ceci est illustré par l'exemple ci-dessous qui ajoute un nouveau titre
devrait commencer par mot-clé à la bibliothèque Selenium . Cet exemple utilise
Python, mais vous pouvez évidemment étendre de la même manière une
bibliothèque Java existante en code Java.
à partir de SeleniumLibrary import SeleniumLibrary

classe ExtendedSeleniumLibrary ( SeleniumLibrary ):

def title_should_start_with ( self , expected ):

title = self . get_title ()
si pas le titre . startswith ( attendu ):
raise AssertionError ( "Le titre ' % s ' n'a pas commencé avec
' % s '"
% ( title , expected ))

Une grande différence avec cette approche par rapport à la modification de la

bibliothèque d'origine est que la nouvelle bibliothèque porte un nom différent de
l'original. Un avantage est que vous pouvez facilement dire que vous utilisez une
bibliothèque personnalisée, mais un gros problème est que vous ne pouvez pas
facilement utiliser la nouvelle bibliothèque avec l'original. Tout d'abord, votre
nouvelle bibliothèque aura les mêmes mots-clés que l'original, ce qui signifie qu'il
y a toujours des conflits . Un autre problème est que les bibliothèques ne partagent
pas leur état.

Cette approche fonctionne bien lorsque vous commencez à utiliser une nouvelle
bibliothèque et souhaitez y ajouter des améliorations personnalisées dès le
début. Sinon, les autres mécanismes expliqués dans cette section sont probablement
meilleurs.

Utiliser d'autres bibliothèques directement

Étant donné que les bibliothèques de test ne sont techniquement que des classes ou
des modules, un moyen simple d’utiliser une autre bibliothèque consiste à
l’importer et à utiliser ses méthodes. Cette approche fonctionne bien lorsque les
méthodes sont statiques et ne dépendent pas de l'état de la bibliothèque. Ceci est
illustré par l'exemple précédent qui utilise la bibliothèque BuiltIn de Robot Framework .

Si la bibliothèque a un état, cependant, les choses pourraient ne pas fonctionner

comme vous le souhaiteriez. L'instance de bibliothèque que vous utilisez dans votre
bibliothèque ne sera pas la même que celle utilisée par la structure. Par conséquent,
les modifications effectuées par les mots clés exécutés ne sont pas visibles par votre
bibliothèque. La section suivante explique comment accéder à la même instance de
bibliothèque que l'infrastructure utilise.

Obtenir une instance de bibliothèque active à partir de Robot

Framework
Mot clé incorporé L' instance de bibliothèque peut être utilisée pour obtenir l'instance
de bibliothèque actuellement active à partir de la structure elle-même. L'instance de
bibliothèque renvoyée par ce mot clé est la même que celle utilisée par le
framework, et il n'y a donc aucun problème à voir l'état correct de la
bibliothèque. Bien que cette fonctionnalité soit disponible en tant que mot clé, elle
est généralement utilisée directement dans les bibliothèques de tests en important
la classe de bibliothèque BuiltIn , comme indiqué précédemment . L'exemple suivant
montre comment implémenter le même mot-clé dont le mot-clé doit commencer
avec un exemple, comme dans l'exemple précédent sur l' utilisation de l'héritage .
à partir de robot.libraries.BuiltIn import BuiltIn

def title_should_start_with ( attendu ):

seleniumlib = BuiltIn () . get_library_instance ( 'SeleniumLibrary' )
title = séléniumlib . get_title ()
si pas le titre . startswith ( attendu ):
raise AssertionError ( "Le titre ' % s ' n'a pas commencé avec ' %
s '"
% ( titre , attendu ))

Cette approche est clairement meilleure que l’importation directe de la bibliothèque

et son utilisation lorsque la bibliothèque a un état. Le plus grand avantage sur
l'héritage est que vous pouvez utiliser la bibliothèque d'origine normalement et
utiliser la nouvelle bibliothèque en plus si nécessaire. Cela est démontré dans
l'exemple ci-dessous où le code des exemples précédents devrait être disponible
dans une nouvelle bibliothèque SeLibExtensions .
*** Paramètres ***
Bibliothèque SeleniumLibrary
Bibliothèque SeLibExtensions

*** Cas de test ***

Exemple
Navigateur ouvert http: // exemple # Le titre de SeleniumLibrary doit
commencer par l' exemple # SeLibExtensions

Bibliothèques utilisant l'API dynamique ou hybride

Les bibliothèques de test qui utilisent l' API de bibliothèque dynamique ou hybride ont
souvent leurs propres systèmes pour les étendre. Avec ces bibliothèques, vous
devez demander conseil aux développeurs de la bibliothèque ou consulter la
documentation de la bibliothèque ou le code source.
4.2 Interface de bibliothèque distante
L'interface de la bibliothèque distante fournit des moyens d'avoir des bibliothèques
de test sur des machines différentes que celles où Robot Framework lui-même est
exécuté, ainsi que d'implémenter des bibliothèques utilisant d'autres langages que
Python et Java pris en charge en natif. Pour une bibliothèque de test, les
bibliothèques distantes utilisateur ressemblent à peu près à toute autre bibliothèque
de test et le développement de bibliothèques de test à l'aide de l'interface de
bibliothèque distante est également très proche de la création de bibliothèques de test
normales .

 4.2.1 Introduction
 4.2.2 Utilisation de la bibliothèque distante
o Importer une bibliothèque distante
o Démarrage et arrêt de serveurs distants
 4.2.3 Arguments et types de valeur de retour pris en charge
 4.2.4 Protocole à distance
o Méthodes requises
o Obtenir des noms de mots clés distants et d'autres informations
o Exécution de mots-clés distants
o Différentes syntaxes d'arguments

4.2.1 Introduction
Il y a deux raisons principales pour utiliser l'API de la bibliothèque distante:

 Il est possible d'avoir des bibliothèques réelles sur des machines différentes
de celles où Robot Framework est exécuté. Cela permet des possibilités
intéressantes pour les tests distribués.
 Les bibliothèques de test peuvent être implémentées dans n'importe quel
langage prenant en charge le protocole XML-RPC . Il existe des serveurs
distants génériques prêts à l'emploi pour différents langages tels que Python,
Java, Ruby, .NET, etc.

L'interface de la bibliothèque distante est fournie par la bibliothèque distante qui est
l'une des bibliothèques standard . Cette bibliothèque n'a pas de mot-clé, mais elle
fonctionne comme un proxy entre la structure principale et les mots-clés mis en
œuvre ailleurs. La bibliothèque distante interagit avec les implémentations de
bibliothèque réelles via des serveurs distants et la bibliothèque et les serveurs
distants communiquent à l'aide d'un protocole distant simple au-dessus d'un canal
XML-RPC. L'architecture de haut niveau de tout cela est illustrée dans l'image ci-
dessous:
Architecture de cadre robotique avec bibliothèque distante

Remarque

Le client distant utilise le module xmlrpclib standard de Python . Il ne prend pas en charge les
extensions XML-RPC personnalisées implémentées par certains serveurs XML-RPC.

4.2.2 Utilisation de la bibliothèque distante

Importer une bibliothèque distante
La bibliothèque distante doit connaître l'adresse du serveur distant, mais l'importer
et utiliser les mots clés fournis diffère de la façon dont les autres bibliothèques sont
utilisées. Si vous devez utiliser la bibliothèque distante plusieurs fois dans une suite
de tests, ou simplement lui donner un nom plus descriptif, vous pouvez l'importer à
l'aide de la syntaxe WITH NAME .
*** Paramètres ***
Bibliothèque distante http://127.0.0.1:8270 AVEC NOM Exemple1
Bibliothèque distante http://example.com:8080/ AVEC NOM Exemple2
Bibliothèque distante http://10.0.0.2/exemple 1 minute AVEC NOM Exemple3

L'URL utilisée par le premier exemple ci-dessus est également l'adresse par défaut
utilisée par la bibliothèque distante si aucune adresse n'est donnée.

Le dernier exemple ci-dessus montre comment accorder un délai d'attente

personnalisé à la bibliothèque distante en tant que second argument facultatif. Le
délai d'attente est utilisé lors de la connexion initiale au serveur et si une connexion
se ferme accidentellement. Le timeout peut être donné dans le format d'heure
de Robot Framework comme 60sou 2 minutes 10 seconds. Le délai d'attente par
défaut est généralement de plusieurs minutes, mais cela dépend du système
d'exploitation et de sa configuration. Notez que la définition d'un délai plus court
que le temps d'exécution du mot clé interrompt le mot clé. La définition d'un délai
d'attente personnalisé ne fonctionne pas avec IronPython.

Remarque
Port 8270est le port par défaut que les serveurs distants sont censés utiliser et a été enregistré
par l'IANA à cette fin. Ce numéro de port a été sélectionné car 82 et 70 sont les codes ASCII
des lettres Ret F, respectivement.

Remarque

Lors de la connexion à la machine locale, il est recommandé d'utiliser l'adresse

IP 127.0.0.1au lieu du nom de la machine localhost. Cela évite la résolution des adresses
qui peut être extrêmement lente au moins sous Windows .

Remarque

Si l'URI ne contient aucun chemin après l'adresse du serveur, le module xmlrpclib utilisé par
la bibliothèque distante utilisera le /RPC2chemin par défaut. En pratique,
l'utilisation http://127.0.0.1:8270est donc identique à
l'utilisation http://127.0.0.1:8270/RPC2. Selon le serveur distant, cela peut ne pas être un
problème. Aucun chemin supplémentaire n'est ajouté si l'adresse a un chemin, même si le
chemin est juste /. Par exemple,
ni http://127.0.0.1:8270/ni ni ne http://127.0.0.1:8270/my/pathseront modifiés.

Démarrage et arrêt de serveurs distants

Avant que la bibliothèque distante puisse être importée, le serveur distant
fournissant les mots-clés réels doit être démarré. Si le serveur est démarré avant de
lancer l'exécution du test, il est possible d'utiliser le paramètre
de bibliothèque normal , comme dans l'exemple ci-dessus. D'autres mots clés, par
exemple ceux des bibliothèques Process ou SSH , peuvent démarrer le serveur, mais
vous devrez peut-être utiliser le mot clé Import Library car la bibliothèque n'est pas
disponible au démarrage de l'exécution du test.

La façon dont un serveur distant peut être arrêté dépend de la manière dont il est
implémenté. En règle générale, les serveurs prennent en charge les méthodes
suivantes:

 Quelle que soit la bibliothèque utilisée, les serveurs distants doivent fournir
le mot clé Stop Remote Server qui peut être facilement utilisé par les tests
exécutés.
 Les serveurs distants doivent avoir une stop_remote_serverméthode dans
leur interface XML-RPC.
 Frapper Ctrl-Csur la console sur laquelle le serveur est en cours d'exécution
doit arrêter le serveur.
 Le processus du serveur peut être interrompu à l'aide des outils fournis par le
système d'exploitation (par exemple, kill ).

Remarque
Les serveurs peuvent être configurés pour que les utilisateurs ne puissent pas l'arrêter avec
le mot clé ou la méthode Arrêter le serveur distantstop_remote_server .

4.2.3 Arguments et types de valeur de retour pris en

charge
Le protocole XML-RPC ne prenant pas en charge tous les types d'objet possibles,
les valeurs transférées entre la bibliothèque distante et les serveurs distants doivent
être converties en types compatibles. Cela s'applique aux arguments de mot-clé que
la bibliothèque distante transmet aux serveurs distants et aux valeurs renvoyées par
les serveurs à la bibliothèque distante.

La bibliothèque distante et le serveur distant Python traitent tous deux les valeurs
Python conformément aux règles suivantes. Les autres serveurs distants doivent se
comporter de la même manière.

 Les chaînes, les nombres et les valeurs booléennes sont transmis sans
modification.
 Python Noneest converti en une chaîne vide.
 Toutes les listes, les tuples et autres objets itérables (à l'exception des
chaînes et des dictionnaires) sont transmis en tant que listes afin que leur
contenu soit converti de manière récursive.
 Les dictionnaires et autres mappages sont passés en tant que dictionnaires
afin que leurs clés soient converties en chaînes et que les valeurs soient
converties en types pris en charge de manière récursive.
 Les dictionnaires renvoyés sont convertis en dicts dits accessibles par des
points qui permettent d'accéder aux clés en tant qu'attributs en utilisant
la syntaxe de la variable étendue comme ${result.key}. Cela fonctionne
également avec les dictionnaires imbriqués comme ${root.child.leaf}.
 Les chaînes contenant des octets dans la plage ASCII qui ne peuvent pas être
représentés en XML (par exemple, l'octet nul) sont envoyées en tant qu'objets
binaires utilisant en interne le type de données XML-RPC base64. Les objets
binaires reçus sont automatiquement convertis en chaînes d'octets.
 Les autres types sont convertis en chaînes.

Remarque

Avant Robot Framework 2.8.3, seules les listes, les tuples et les dictionnaires étaient traités
conformément aux règles ci-dessus. Les itérations générales et les mappages n'étaient pas pris
en charge. De plus, le support binaire est nouveau dans Robot Framework 2.8.4 et les
dictionnaires accessibles par des points sont à nouveau disponibles dans Robot Framework
2.9.

4.2.4 Protocole à distance

Cette section explique le protocole utilisé entre la bibliothèque distante et les
serveurs distants. Ces informations sont principalement destinées aux personnes
souhaitant créer de nouveaux serveurs distants. Les serveurs Python et Ruby
fournis peuvent également être utilisés comme exemples.

Le protocole distant est implémenté au-dessus de XML-RPC , qui est un protocole

d'appel de procédure à distance simple utilisant XML sur HTTP. La plupart des
langages traditionnels (Python, Java, C, Ruby, Perl, Javascript, PHP, ...) prennent
en charge XML-RPC intégré ou en tant qu'extension.

Méthodes requises
Un serveur distant est un serveur XML-RPC qui doit avoir les mêmes méthodes
dans son interface publique que l' API de bibliothèque
dynamique . Seuls get_keyword_names et run_keywordsont effectivement nécessaires,
mais get_keyword_arguments, get_keyword_tagset get_keyword_documentationsont
également recommandés. Notez que l'utilisation du format camelCase
comme getKeywordNamesdans les noms de méthode n'est pas possible de la même
manière que dans l'API dynamique normale. La manière dont les mots-clés réels
sont implémentés n'est pas pertinente pour la bibliothèque distante. Les serveurs
distants peuvent soit servir de wrappers pour les bibliothèques de test réelles,
comme le font les serveurs distants génériques disponibles , soit implémenter des
mots-clés eux-mêmes.

Les serveurs distants devraient en outre disposer

d'une stop_remote_server méthode dans leur interface publique pour les arrêter
facilement. Ils doivent également exposer automatiquement cette méthode en tant
que mot clé Stop Remote Server pour permettre son utilisation dans les données de
test, quelle que soit la bibliothèque de test. Autoriser les utilisateurs à arrêter le
serveur n'est pas toujours souhaitable et les serveurs peuvent prendre en charge la
désactivation de cette fonctionnalité. La méthode, ainsi que le mot-clé exposé,
doivent renvoyer True ou Falseselon que l'arrêt est autorisé ou non. Cela permet
aux outils externes de savoir si l’arrêt du serveur a réussi.

Le serveur distant Python peut être utilisé comme une implémentation de référence.

Obtenir des noms de mots clés distants et d'autres informations

La bibliothèque distante obtient la liste des mots-clés fournis par un serveur distant
à l'aide de la get_keyword_namesméthode. Les serveurs distants doivent
implémenter cette méthode et la méthode doit renvoyer les noms de mots-clés sous
la forme d'une liste de chaînes.

Les serveurs distants peuvent, et doivent, aussi mettre

en œuvre get_keyword_arguments, get_keyword_tagset
les get_keyword_documentationméthodes pour fournir plus d' informations sur les
mots - clés. Toutes ces méthodes prennent le nom du mot-clé en argument. Les
arguments doivent être renvoyés sous la forme d'une liste de chaînes au même
format que les bibliothèques dynamiques , les balises en tant que liste de chaînes et la
documentation en tant que chaîne .

Les serveurs distants peuvent également fournir une documentation générale sur la
bibliothèque à utiliser lors de la génération de la documentation avec l' outil Libdoc .

Remarque

get_keyword_tagsest nouveau dans Robot Framework 3.0.2. Avec les versions antérieures,
les étiquettes de mots-clés peuvent être incorporées dans la documentation du mot-clé .

Exécution de mots-clés distants

Lorsque la bibliothèque distante souhaite que le serveur exécute des mots-clés, elle
appelle la run_keywordméthode du serveur distant et lui transmet le nom du mot-clé,
une liste d'arguments et éventuellement un dictionnaire d' arguments de mots-clés
gratuits . Les types de base peuvent être utilisés directement comme arguments,
mais des types plus complexes sont convertis en types pris en charge .

Le serveur doit renvoyer les résultats de l'exécution dans un dictionnaire de

résultats (ou une carte, selon la terminologie) contenant les éléments expliqués dans
le tableau suivant. Notez que seule l' statusentrée est obligatoire, d'autres peuvent
être omises si elles ne sont pas applicables.

Entrées dans le dictionnaire de résultats distant

prénom Explication

statut Statut d'exécution obligatoire. Soit PASS ou FAIL.

sortie Sortie possible pour écrire dans le fichier journal. Doit être donné sous forme de
chaîne unique mais peut contenir plusieurs messages et différents niveaux de
journalisation au format *INFO* First message\n*HTML*
<b>2nd</b>\n*WARN* Another message. Il est également possible d'intégrer
des horodatages aux messages du journal comme*INFO:1308435758660*
Message with timestamp.

revenir Valeur de retour possible. Doit être l'un des types pris en charge .

Erreur Message d'erreur possible. Utilisé uniquement lorsque l'exécution échoue.

traceback Trace de trace possible pour écrire dans le fichier journal à l' aide du niveau
DEBUG lorsque l'exécution échoue.

continuable Lorsqu'elle est définie sur Trueou sur toute valeur considérée Truedans Python,
l'échec survenu est considéré comme continuable . Nouveau dans Robot Framework
2.8.4.
 Entrées dans le dictionnaire de résultats distant

prénom Explication

fatal Comme continuable, mais indique que l'échec survenu est fatal . Aussi nouveau
dans Robot Framework 2.8.4.

Différentes syntaxes d'arguments

La bibliothèque distante est une bibliothèque dynamique et, en général, elle gère
différentes syntaxes d'argument selon les mêmes règles que toute autre bibliothèque
dynamique. Cela inclut les arguments obligatoires, les valeurs par défaut, varargs,
ainsi que la syntaxe des arguments nommés .

De même, les mots-clés arguments ( **kwargs) fonctionnent de la même manière

qu'avec les autres bibliothèques dynamiques . Tout d'abord,
le get_keyword_argumentsdoit renvoyer une spécification d'argument qui
contient **kwargsexactement comme avec toute autre bibliothèque dynamique. La
principale différence est que la run_keywordméthode des serveurs distants doit avoir
un troisième argument optionnel qui obtient les kwarg spécifiés par l'utilisateur. Le
troisième argument doit être facultatif car, pour des raisons de rétrocompatibilité, la
bibliothèque distante transmet kwargs à la run_keywordméthode uniquement
lorsqu'elle a été utilisée dans les données de test.

En pratique, cela run_keyworddevrait ressembler aux exemples Python et Java

suivants, en fonction de la manière dont le langage gère les arguments facultatifs.
def run_keyword ( name , args , kwargs = None ):
# ...
map publique run_keyword ( nom de la chaîne , args de la liste ) { //
... }

map publique run_keyword ( nom de chaîne , args de liste , kwargs de

carte ) { // ... }

Remarque

Prise en charge des bibliothèques distantes à **kwargspartir de Robot Framework 2.8.3.

4.3 Interface auditeur

Robot Framework a une interface d'écoute qui peut être utilisée pour recevoir des
notifications sur l'exécution des tests. Les exemples d'utilisation incluent des
moniteurs de test externes, l'envoi d'un message électronique en cas d'échec d'un
test et la communication avec d'autres systèmes. La version 3 de l'API d'écouteur
permet également de modifier les tests et les résultats lors de l'exécution du test.

Les auditeurs sont des classes ou des modules avec certaines méthodes spéciales, et
ils peuvent être implémentés à la fois avec Python et Java. Les auditeurs qui
surveillent l'exécution complète du test doivent être utilisés à partir de la ligne de
commande. De plus, les bibliothèques de test peuvent enregistrer des écouteurs qui
reçoivent des notifications lorsque cette bibliothèque est active.

 4.3.1 Utilisation des auditeurs

 4.3.2 Versions de l'interface d'écoute
 4.3.3 Méthodes d'interface d'écoute
o Version d'auditeur 2
o Version auditeur 3
 4.3.4 Journaux d'écoute
 4.3.5 Exemples d'écoute
o Obtenir des informations
o Modifier l'exécution et les résultats
 4.3.6 Test des bibliothèques en tant qu’auditeurs
o Enregistrement de l'auditeur
o Appelé les méthodes d'écoute

4.3.1 Utilisation des auditeurs

Les écouteurs sont utilisés à partir de la ligne de commande avec l' option --
listener afin que le nom de l'écouteur lui soit donné en tant qu'argument. Le
nom du programme d'écoute est obtenu à partir du nom de la classe ou du module
implémentant l'interface du programme d'écoute, tout comme les noms des
bibliothèques de tests proviennent des classes les implémentant. Les écouteurs
spécifiés doivent se trouver dans le même chemin de recherche de module où les
bibliothèques de tests sont recherchées à partir de leur importation. Une autre
option consiste à donner un chemin absolu ou relatif au fichier d'écoute de la même
manière qu'avec les bibliothèques de test . Il est possible d'utiliser plusieurs auditeurs en
utilisant cette option plusieurs fois:
robot - listener MyListener tests.robot
robot --listener com.company.package.Listener tests.robot
robot - chemin d'accès à / myListener.py tests.robot
robot --listener module.Listener --listener AnotherListener
tests.robot

Il est également possible de donner des arguments aux classes d'écoute depuis la
ligne de commande. Les arguments sont spécifiés après le nom de l'écouteur (ou
chemin) en utilisant deux points ( :) comme séparateur. Si un écouteur est fourni en
tant que chemin d'accès Windows absolu, les deux points après la lettre de lecteur
ne sont pas considérés comme un séparateur. À partir de Robot Framework 2.8.7, il
est possible d'utiliser un point-virgule ( ;) comme séparateur d'argument
alternatif. Ceci est utile si les arguments de l'écouteur contiennent eux-mêmes des
deux-points, mais requièrent que la valeur entière soit entourée de guillemets sur
les systèmes d'exploitation de type UNIX:
robot --listener listener.py:arg1:arg2 tests.robot
robot --listener "listener.py; arg: with: colons" tests.robot
robot - listener C: \ Path \ Listener.py; D: \ data; E: \ extra
tests.robot

4.3.2 Versions de l'interface d'écoute

Il existe deux versions d'interface d'écoute prises en charge. La version 2 de
l'écouteur est disponible depuis Robot Framework 2.1 et la version 3 est prise en
charge par Robot Framework 3.0 et versions ultérieures. Un écouteur doit avoir un
attribut ROBOT_LISTENER_API_VERSIONde valeur 2 ou 3, sous forme de chaîne ou
d'entier, en fonction de la version de l'API utilisée. Il y a également eu un ancien
auditeur version 1, mais Robot Framework 3.0 ne le prend plus en charge.

La principale différence entre les versions d'écoute 2 et 3 est que la première

n'obtient que des informations sur l'exécution, mais ne peut pas l'affecter
directement. La dernière interface récupère les données et les objets de résultat que
Robot Framework utilise lui-même et peut donc modifier l'exécution et modifier les
résultats. Voir les exemples d'écouteurs pour plus d'informations sur ce que les
auditeurs peuvent faire.

Une autre différence entre les versions 2 et 3 est que la première prend en charge à
la fois Python et Java, mais la seconde ne prend en charge que Python.

4.3.3 Méthodes d'interface d'écoute

Robot Framework crée des instances de classes d'écouteur au démarrage de
l'exécution du test et utilise directement des écouteurs implémentés en tant que
modules. Au cours de l'exécution du test, différentes méthodes d'écouteur sont
appelées lorsque les suites de tests, les scénarios de test et les mots clés
commencent et se terminent. Des méthodes supplémentaires sont appelées
lorsqu'une bibliothèque ou un fichier de ressources ou de variables est importé,
lorsque les fichiers de sortie sont prêts et finalement lorsque l'exécution du test
prend fin. Un auditeur n’est pas obligé d’implémenter une interface officielle et il
lui suffit d’avoir les méthodes dont il a réellement besoin.

Les versions d'écoute 2 et 3 utilisent principalement les mêmes méthodes, mais les
arguments qu'elles acceptent sont différents. Ces méthodes et leurs arguments sont
expliqués dans les sections suivantes. Toutes les méthodes qui ont un trait de
soulignement dans leur nom ont aussi l' alternative camelCase . Par exemple,
la start_suiteméthode peut également être utilisée avec le nom startSuite.
Version d'auditeur 2
Les méthodes d'écoute de l'API version 2 sont répertoriées dans le tableau
suivant. Toutes les méthodes liées à la progression de l'exécution du test ont la
même signature method(name, attributes), où se attributestrouve un dictionnaire
contenant les détails de l'événement. Les méthodes d'écoute sont libres de faire ce
qu'elles veulent avec les informations qu'elles reçoivent, mais elles ne peuvent pas
le changer directement. Si cela est nécessaire, l' écouteur version 3 peut être utilisé à
la place.

Méthodes dans l'API d'écouteur 2

Méthode Arguments Documentation

start_suite nom, Appelé quand une suite de tests démarre.

attributs
Contenu du dictionnaire d'attributs:

 id: Identifiant de la suite. s1pour la suite de premier

niveau, s1-s1 pour sa première suite enfant, s1-
s2pour le deuxième enfant, etc. Nouveau dans RF 2.8.5.
 longname: Nom de la suite, y compris les suites
parentales.
 doc: Documentation de la suite.
 metadata: Métadonnées gratuites de la suite de
tests sous forme de dictionnaire / map.
 source: Un chemin absolu du fichier / répertoire à
partir duquel la suite a été créée. Nouveau dans RF 2.7.
 suites: Noms des suites enfants directes que cette suite
a comme liste.
 tests: Noms des tests de cette suite sous forme de
liste. Ne comprend pas les tests des suites enfants
possibles.
 totaltests: Le nombre total de tests dans cette
suite. et toutes ses sous-suites sous forme d'entier.
 starttime: Heure de début d'exécution de la suite.
end_suite nom, Appelé à la fin d'une suite de tests
attributs
Contenu du dictionnaire d'attributs:

 id: Identique à start_suite.

 longname: Identique à start_suite.
 doc: Identique à start_suite.
 metadata: Identique à start_suite.
 source: Identique à start_suite.
 starttime: Identique à start_suite.
 endtime: Heure de fin de l'exécution de la suite.
Méthodes dans l'API d'écouteur 2

Méthode Arguments Documentation

 elapsedtime: Temps d'exécution total en
millisecondes sous forme d'entier
 status: État de la suite sous forme de
chaîne PASSou FAIL.
 statistics: Statistiques de la suite (nombre de tests
réussis et échoués dans la suite) sous forme de chaîne.
 message: Message d'erreur si l'installation ou le
démontage de la suite a échoué, vide sinon.
start_test nom, Appelé quand un scénario de test démarre.
attributs
Contenu du dictionnaire d'attributs:

 id: Identifiant de test au format comme s1-s2-t2, où

le début est l'identifiant de la suite parentale et la
dernière partie montre l'index de test dans cette
suite. Nouveau dans RF 2.8.5.
 longname: Nom du test, y compris les suites parentales.
 doc: Documentation de test.
 tags: Testez les balises comme une liste de chaînes.
 critical: yesou en nofonction du test considéré
critique ou non.
 template: Le nom du modèle utilisé pour le test. Une
chaîne vide si le test n'est pas basé sur un modèle.
 starttime: Test de l'heure de début de l'exécution de
l'exécution.
end_test nom, Appelé à la fin d'un test
attributs
Contenu du dictionnaire d'attributs:

 id: Identique à start_test.

 longname: Identique à start_test.
 doc: Identique à start_test.
 tags: Identique à start_test.
 critical: Identique à start_test.
 template: Identique à start_test.
 starttime: Identique à start_test.
 endtime: Teste l'heure de fin d'exécution d'exécution.
 elapsedtime: Temps d'exécution total en
millisecondes sous forme d'entier
 status: Statut du test sous forme de
chaîne PASSou FAIL.
 message: Message d'état Normalement, un message
d'erreur ou une chaîne vide.
Méthodes dans l'API d'écouteur 2

Méthode Arguments Documentation

start_keyword nom, Appelé lorsqu'un mot clé commence
attributs
nameest le nom complet du mot clé contenant un nom de
bibliothèque ou de ressource possible en tant que préfixe. Par
exemple MyLibrary.Example Keyword,.

Contenu du dictionnaire d'attributs:

 type: Chaîne Keywordpour les mots-clés

normaux Setupou Teardownpour le mot-clé de
premier niveau utilisé comme configuration /
démontage, Forpour les boucles For Itemfor et pour
les itérations en boucle. REMARQUE: Les rapports de
type de mot - clé ont été modifiés dans RF 3.0. Voir le
numéro 2248 pour plus de détails.
 kwname: Nom du mot-clé sans préfixe de bibliothèque
ou de ressource. Nouveau dans RF 2.9.
 libname: Nom de la bibliothèque ou de la ressource à
laquelle appartient le mot clé ou chaîne vide lorsque le
mot clé se trouve dans un fichier de scénario de
test. Nouveau dans RF 2.9.
 doc: Documentation sur les mots clés.
 args: Les arguments du mot clé sous forme de liste de
chaînes.
 assign: Une liste de noms de variables à laquelle la
valeur de retour du mot clé est affectée. Nouveau dans
RF 2.9.
 tags: Tags de mots-clés en tant que liste de
chaînes. Nouveau dans RF 3.0.
 starttime: Heure de début d'exécution du mot clé.
end_keyword nom, Appelé à la fin d'un mot clé
attributs
nameest le nom complet du mot clé contenant un nom de
bibliothèque ou de ressource possible en tant que préfixe. Par
exemple MyLibrary.Example Keyword,.

Contenu du dictionnaire d'attributs:

 type: Comme avec start_keyword.

 kwname: Comme avec start_keyword.
 libname: Comme avec start_keyword.
 doc: Comme avec start_keyword.
 args: Comme avec start_keyword.
 assign: Comme avec start_keyword.
 tags: Comme avec start_keyword.
Méthodes dans l'API d'écouteur 2

Méthode Arguments Documentation

 starttime: Comme avec start_keyword.
 endtime: Heure de fin de l'exécution du mot clé.
 elapsedtime: Temps d'exécution total en
millisecondes sous forme d'entier
 status: Etat du mot clé sous forme de
chaîne PASSou FAIL.
log_message message Appelé lorsqu'un mot clé exécuté écrit un message de journal.

message est un dictionnaire avec les contenus suivants:

 message: Le contenu du message.

 level: Niveau de journal utilisé pour la journalisation
du message.
 timestamp: Heure de création du message au
format YYYY-MM-DD hh:mm:ss.mil.
 html: Chaîne yesou noindiquant si le message doit être
interprété en HTML ou non.

À partir de RF 3.0, cette méthode n'est pas appelée si le message

a un niveau inférieur au niveau de seuil actuel .
message message Appelé lorsque le framework lui-même écrit un message syslog .

messageest un dictionnaire avec le même contenu qu'avec

la log_messageméthode.
import_librairie nom, Appelé lorsqu'une bibliothèque a été importée.
attributs
nameest le nom de la bibliothèque importée. Si la bibliothèque a
été importée à l'aide de la syntaxe WITH NAME , nameest
l'alias spécifié.

Contenu du dictionnaire d'attributs:

 args: Arguments transmis à la bibliothèque sous forme

de liste.
 originalname: Le nom de la bibliothèque d'origine
lors de l'utilisation de la syntaxe WITH NAME, sinon
identique à name.
 source: Un chemin absolu vers la source de la
bibliothèque. None avec les bibliothèques implémentées
avec Java ou si obtenir la source de la bibliothèque a
échoué pour une raison quelconque.
 importer: Un chemin absolu vers le fichier
d'importation de la
bibliothèque. Nonelorsque BuiltIn est importé ainsi que
lors de l'utilisation du mot clé Import Library .
Méthodes dans l'API d'écouteur 2

Méthode Arguments Documentation

Nouveau dans Robot Framework 2.9.

import_ressource nom, Appelé lorsqu'un fichier de ressources a été importé.
attributs
name est le nom du fichier de ressources importé sans
l'extension de fichier.

Contenu du dictionnaire d'attributs:

 source: Un chemin absolu vers le fichier de ressources

importé.
 importer: Un chemin absolu vers le fichier
d'importation du fichier de ressources. Nonelors de
l'utilisation du mot clé Import Resource .

Nouveau dans Robot Framework 2.9.

variables_import nom, Appelé lorsqu'un fichier de variable a été importé.
attributs
name est le nom du fichier de variables importé avec l'extension
de fichier.

Contenu du dictionnaire d'attributs:

 args: Arguments transmis au fichier de variables sous

forme de liste.
 source: Un chemin absolu vers le fichier de variable
importé.
 importer: Un chemin absolu vers le fichier
d'importation du fichier de ressources. Nonelors de
l'utilisation du mot clé Import Variables .

Nouveau dans Robot Framework 2.9.

fichier de sortie chemin Appelé lors de l'écriture dans un fichier de sortie est prêt.

path est un chemin absolu vers le fichier.

fichier journal chemin Appelé lors de l'écriture dans un fichier journal est prêt.

path est un chemin absolu vers le fichier.

report_file chemin Appelé lors de l'écriture dans un fichier de rapport est prêt.

path est un chemin absolu vers le fichier.

xunit_file chemin Appelée lors de l'écriture dans un fichier xunit est prête.

path est un chemin absolu vers le fichier.

debug_file chemin Appelé lors de l'écriture dans un fichier de débogage est prêt.
 Méthodes dans l'API d'écouteur 2

Méthode Arguments Documentation

path est un chemin absolu vers le fichier.
Fermer Appelé à la fin de l'exécution du test complet.

Avec les écouteurs de bibliothèque appelés lorsque la

bibliothèque est hors de portée.

Les méthodes disponibles et leurs arguments sont également présentés dans une
spécification d'interface Java formelle ci-dessous. Le contenu du java.util.Map
attributessont comme dans le tableau ci-dessus. Il ne faut pas oublier qu'un
auditeur n'a pas besoin d'implémenter une interface explicite ou d'avoir toutes ces
méthodes.
interface publique RobotListenerInterface {
public static final int ROBOT_LISTENER_API_VERSION = 2 ;
void startSuite ( nom de la chaîne , java . util . attributs de la
carte ); void endSuite ( nom de la chaîne , java . util . attributs de
carte ); void startTest ( nom de la chaîne , java . util .

Attributs de la carte );
void endTest ( nom de la chaîne , java . util . attributs de la carte
); void startKeyword ( nom de la chaîne , java . util . attributs de la
carte ); void endKeyword ( nom de la chaîne , java . util . attributs de la
carte ); annuler le logMessage ( java . util . Map

message );
message annulé ( java . util . Message carte ); void outputFile (
chemin de chaîne ); void logFile ( chemin de la chaîne ); void reportFile (
chemin de la chaîne ); void debugFile ( chemin de la chaîne ); void close
(); }

Version auditeur 3
La version 3 de l'auditeur utilise principalement les mêmes méthodes que la version
2 de l'écouteur mais les arguments des méthodes liées à l'exécution des tests sont
différents. Cette API obtient les objets de modèle d'exécution et de résultat réels
utilisés par Robot Framework lui-même, et les auditeurs peuvent à la fois interroger
directement les informations dont ils ont besoin et modifier les objets du modèle à
la volée.

La version 3 de l'auditeur a été introduite dans Robot Framework 3.0. Au moins au

début, il ne possède pas toutes les méthodes de la version 2. La raison principale est
que les objets de modèle appropriés ne sont pas disponibles en interne . La closeméthode
et les méthodes associées aux fichiers de sortie sont appelées exactement de la
même manière dans les deux versions.

Méthodes dans l'API d'écouteur 3

Méthode Arguments Documentation

start_suite données, Appelé quand une suite de tests démarre.

résultat
dataet resultsont des objets de modèle représentant
respectivement la suite de tests exécutée et ses résultats
d'exécution .
end_suite données, Appelé à la fin d'une suite de tests
résultat
Mêmes arguments qu'avec start_suite.
start_test données, Appelé quand un scénario de test démarre.
résultat
dataet resultsont des objets de modèle représentant le cas
de test exécuté et ses résultats d'exécution , respectivement.
end_test données, Appelé à la fin d'un test
résultat
Mêmes arguments qu'avec start_test.
start_keyword N/A Non implémenté dans RF 3.0.
end_keyword N/A Non implémenté dans RF 3.0.
log_message message Appelé lorsqu'un mot clé exécuté écrit un message de
journal. messageest un objet de modèle représentant
le message enregistré.

Cette méthode n'est pas appelée si le message a un niveau

inférieur au niveau de seuil actuel .
message message Appelé lorsque le framework lui-même écrit
un message syslog .

messageest le même objet qu'avec log_message.

import_librairie N/A Non implémenté dans RF 3.0.
import_ressource N / A Non implémenté dans RF 3.0.
variables_import N / A Non implémenté dans RF 3.0.
fichier de sortie chemin Appelé lors de l'écriture dans un fichier de sortie est prêt.

path est un chemin absolu vers le fichier.

fichier journal chemin Appelé lors de l'écriture dans un fichier journal est prêt.

path est un chemin absolu vers le fichier.

report_file chemin Appelé lors de l'écriture dans un fichier de rapport est prêt.

path est un chemin absolu vers le fichier.

xunit_file chemin Appelée lors de l'écriture dans un fichier xunit est prête.

path est un chemin absolu vers le fichier.

 Méthodes dans l'API d'écouteur 3

Méthode Arguments Documentation

debug_file chemin Appelé lors de l'écriture dans un fichier de débogage est prêt.

path est un chemin absolu vers le fichier.

Fermer Appelé à la fin de l'exécution du test complet.

Avec les écouteurs de bibliothèque appelés lorsque la

bibliothèque est hors de portée.

4.3.4 Journaux d'écoute

Robot Framework offre une API de journalisation programmatique que les auditeurs
peuvent utiliser. Il existe toutefois certaines limites et la manière dont différentes
méthodes d'écoute peuvent consigner les messages est expliquée dans le tableau ci-
dessous.

Comment les méthodes d'écoute peuvent se connecter

Les méthodes Explication

start_keyword, Les messages sont consignés dans le fichier journal normal sous le mot
end_keyword, clé exécuté.
log_message

start_suite, end_suite, Les messages sont enregistrés dans le journal système . Les
start_test, end_teste avertissements sont également affichés dans la section sur les erreurs
d'exécution du fichier journal normal.

message Les messages sont normalement consignés dans le journal système. Si

cette méthode est utilisée pendant l'exécution d'un mot clé, les messages
sont consignés dans le fichier journal normal.

Autres méthodes Les messages ne sont consignés que dans le journal système.

Remarque

Pour éviter la récursivité, les messages enregistrés par les écouteurs ne sont pas envoyés aux
méthodes d'écoute log_messageet message.

4.3.5 Exemples d'écoute

Cette section contient des exemples d'utilisation de l'interface du programme
d'écoute. Il y a des premiers exemples qui ne font que recevoir des informations de
Robot Framework, puis des exemples qui modifient les tests exécutés et créent des
résultats.
Obtenir des informations
Le premier exemple est implémenté en tant que module Python et utilise la version
2 du programme d' écoute .

"" Listener qui arrête l'exécution si un test échoue. "" "

ROBOT_LISTENER_API_VERSION = 2

def end_test ( name , attrs ):

if attrs [ 'status' ] == 'FAIL' :
print 'Test " % s " a échoué: % s ' % ( name , attrs [
'message' ])
raw_input ( 'Appuyez sur Entrée pour continuez. ' )

Si l'exemple ci-dessus est enregistré, par exemple, dans

le fichier PauseExecution.py , il peut être utilisé à partir de la ligne de commande
comme ceci:
robot - chemin d'accès / vers / PauseExecution.py tests.robot

Le même exemple pourrait également être implémenté en utilisant la

nouvelle version 3 du programme d’écoute et être utilisé exactement de la même
manière à partir de la ligne de commande.
"" Listener qui arrête l'exécution si un test échoue. "" "

ROBOT_LISTENER_API_VERSION = 3

def end_test ( données , résultat ):

si pas le résultat . Passé :
print 'Test " % s " a échoué: % s ' % ( résultat . nom ,
résultat . message )
raw_input ( 'Appuyez sur Entrée pour continuer.' )

L'exemple suivant, qui utilise toujours Python, est légèrement plus compliqué. Il
écrit toutes les informations qu'il reçoit dans un fichier texte dans un répertoire
temporaire sans beaucoup de mise en forme. Le nom de fichier peut être donné à
partir de la ligne de commande, mais a également une valeur par défaut. Notez
qu'en mode réel, la fonctionnalité de fichier de débogage disponible via l'option de
ligne de commande --debugfile est probablement plus utile que cet exemple.
import os.path
import tempfile

classe PythonListener :
ROBOT_LISTENER_API_VERSION = 2

def__init__ ( self , filename = 'listen.txt' ):

outpath = os . chemin . join ( tempfile . gettempdir (),
filename )
self . outfile = open ( outpath , 'w' )
 def start_suite ( self , name , attrs ):
self . fichier . write ( " % s ' % s ' \ n " % ( name , attrs [
'doc' ]))

def start_test ( self , name , attrs ):

tags = '' . join ( attrs [ 'tags' ])
self . fichier . write ( "- % s ' % s ' [ % s ] ::" % ( name ,
attrs [ 'doc' ], tags ))

def end_test ( self , name , attrs ):

if attrs [ 'status' ] == 'PASS' :
self . fichier . write ( 'PASS \ n ' )
sinon :
self . fichier . write ( 'FAIL: % s \ n ' % attrs [ 'message'
])

def end_suite ( self , name , attrs ):

self . fichier . write ( ' % s \ n % s \ n ' % ( attrs [
'status' ], attrs [ 'message' ]))

def fermer ( self ):

self . fichier . fermer ()

L'exemple suivant implémente les mêmes fonctionnalités que la précédente, mais

utilise Java au lieu de Python.
import java.io. * ;
import java.util.Map ;
import java.util.List ;

classe publique JavaListener {

public static final int ROBOT_LISTENER_API_VERSION = 2 ;
finale statique publique String DEFAULT_FILENAME = "listen_java.txt" ;
fichier privé BufferedWriter = null ;

public JavaListener () lève IOException {

this ( DEFAULT_FILENAME );
}

public JavaListener ( String filename ) lève IOException {

String tmpdir = System . getProperty ( "java.io.tmpdir" );
String sep = System . getProperty ( "file.separator" );
Chaîne outpath = tmpdir + sep + filename ;
outfile = new BufferedWriter ( nouveau FileWriter ( outpath ));
}

publique vide StartSuite ( chaîne nom , Carte attrs ) jette

IOException {
outfile . write ( name + "'" + attrs . get ( "doc" ) + "' \
n" );
}

publique vide startTest ( chaîne nom , Carte attrs ) jette

IOException {
outfile . write ( "-" + name + "'" + attrs . get ( "doc" ) +
"' [" );
List tags = ( List ) attrs . get ( "tags" );
pour ( int i = 0 ; i < balises . taille (); i ++) {
 fichier de sortie . write ( tags . get ( i ) + "" );
}
fichier . write ( "] ::" );
}

publique vide endTest ( chaîne nom , Carte attrs ) lance

IOException {
chaîne statut = attrs . get ( "status" ). toString ();
if ( status . est égal à ( "PASS" )) {
outfile . write ( "PASS \ n" );
}
else {
fichier de sortie . écrire ( "FAIL:" + attrs . obtenir (
"message" ) + "\ n" );
}
}

publique vide endSuite ( chaîne nom , Carte attrs ) jette

IOException {
outfile . write ( attrs . get ( "status" ) + "\ n" + attrs .
get ( "message" ) + "\ n" );
}

public void close () jette une exception IOException {

outfile . close ();
}
}

Modifier l'exécution et les résultats

Ces exemples illustrent comment modifier les tests et les suites exécutés, ainsi que
les résultats d'exécution. Tous ces exemples nécessitent l'utilisation de l' écouteur
version 3 .

Modification des suites et tests exécutés

Modifier ce qui est exécuté nécessite de modifier l’objet du modèle contenant

la suite de tests ou les objets de cas de test exécutés et passés en premier
argument start_suite et les start_testméthodes. Ceci est illustré par l'exemple ci-
dessous qui ajoute un nouveau test à chaque suite de tests exécutée et un nouveau
mot-clé à chaque test.
ROBOT_LISTENER_API_VERSION = 3

def start_suite ( suite , result ):

suite . tests . create ( name = 'Nouveau test' )

def start_test ( test , result ):

test . mots - clés . create ( name = 'Log' , args = [ 'Mot-clé ajouté
par listener!' ])

Essayer de modifier l'exécution end_suiteou les end_testméthodes ne fonctionne

pas, simplement parce que cette suite ou ce test a déjà été exécuté. Essayer de
modifier le nom, la documentation ou d'autres métadonnées similaires de la suite ou
du test start_suiteou de la start_testméthode en cours ne fonctionne pas non
plus, car l'objet de résultat correspondant a déjà été créé. Seules les modifications
apportées à des tests enfants ou à des mots clés ont un effet.

Cette API est très similaire à l’ API de modificateur pré-exécution qui peut être
utilisée pour modifier des suites et des tests avant le début de l’exécution complète
du test. L'avantage principal de l'utilisation de l'API d'écouteur est que les
modifications peuvent être effectuées dynamiquement en fonction des résultats
d'exécution ou autres. Cela permet, par exemple, des possibilités intéressantes pour
des tests basés sur des modèles.

Bien que l'interface du programme d'écoute ne repose pas sur l' interface
visiteur interne de Robot Framework de la même manière que l'API du modificateur
pré-exécution, les auditeurs peuvent toujours utiliser l'interface des visiteurs eux-
mêmes. Par exemple, le SelectEveryXthTestvisiteur utilisé dans les exemples
de modificateurs pré-analyse pourrait être utilisé comme ceci:
à partir de SelectEveryXthTest import SelectEveryXthTest

ROBOT_LISTENER_API_VERSION = 3

def start_suite ( suite , result ):

selector = SelectEveryXthTest ( x = 2 )
suite . visite ( sélecteur )

Modifier les résultats

Les résultats de l'exécution du test peuvent être modifiés en modifiant les objets de
résultat de la suite de tests et du scénario de test transmis en tant que second
argument start_suiteet start_testméthodes, respectivement, et en modifiant
l' objet message transmis à la log_messageméthode. Ceci est démontré par l'auditeur
suivant qui est implémenté en tant que classe.
class ResultModifier ( objet ):
ROBOT_LISTENER_API_VERSION = 3

def __init__ ( self , max_seconds = 10 ):

self . max_milliseconds = float ( max_seconds ) * 1000

def
start_suite ( self , data , suite ):
suite . doc = 'Documentation définie par l'auditeur.'
# Informations sur les tests disponibles uniquement via les données
à ce stade.
smoke_tests = [ test de test dans les données . tests si
«fumée» en test . tags ]
suite . metadata [ 'Smoke tests' ] = len ( smoke_tests )

def
end_test ( self , data , test ):
si test . status == 'PASS' et test . temps écoulé > auto .
max_milliseconds :
test . status = Test 'FAIL'
. message = 'L'exécution du test a pris trop de temps.'
 def log_message ( self , msg ):
si msg . level == 'WARN' et non msg . html :
msg . message = '<b style = "font-size: 1.5em"> % s </ b>' %
msg . message
msg . html = True

Une limitation est que la modification du nom de la suite de tests ou du scénario

de test en cours n’est pas possible car elle a déjà été écrite dans
le fichier output.xml lorsque les écouteurs sont appelés. Pour la même raison, la
modification de tests déjà terminés dans la end_suiteméthode n’a aucun effet non
plus.

Cette API est très similaire à l’ API de modificateur pré-Rebot qui peut être utilisée
pour modifier les résultats avant que le rapport et le journal ne soient générés. La
principale différence est que les auditeurs modifient également
le fichier output.xml créé .

4.3.6 Test des bibliothèques en tant qu’auditeurs

Parfois, il est également utile que les bibliothèques de tests obtiennent des
notifications sur l'exécution des tests. Cela leur permet, par exemple, d'effectuer
automatiquement certaines activités de nettoyage lorsqu'une suite de tests ou
l'exécution du test complet se termine.

Remarque

Cette fonctionnalité est nouvelle dans Robot Framework 2.8.5.

Enregistrement de l'auditeur
Une bibliothèque de test peut enregistrer un écouteur en utilisant
l' ROBOT_LIBRARY_LISTENER attribut. La valeur de cet attribut doit être une instance
de l'écouteur à utiliser. Il peut s'agir d'un auditeur totalement indépendant ou de la
bibliothèque elle-même. Pour éviter que les méthodes d'écoute soient exposées en
tant que mots-clés dans ce dernier cas, il est possible de les préfixer par un trait de
soulignement. Par exemple, au lieu d'utiliser end_suiteou endSuite, il est possible
d'utiliser _end_suiteou _endSuite.

Les exemples suivants illustrent l'utilisation d'un auditeur externe ainsi que d'une
bibliothèque agissant comme un auditeur lui-même:
import my.project.Listener ;

classe publique JavaLibraryWithExternalListener {

public static final Listener ROBOT_LIBRARY_LISTENER = new
Listener ();
final statique public String ROBOT_LIBRARY_SCOPE = "GLOBAL" ; publique
statique finale int ROBOT_LISTENER_API_VERSION = 2 ;
 // code de la bibliothèque actuelle ici ...
}
classe PythonLibraryAsListenerItself ( objet ):
ROBOT_LIBRARY_SCOPE = 'TEST SUITE'
ROBOT_LISTENER_API_VERSION = 2

def __init__ ( self ):

self . ROBOT_LIBRARY_LISTENER = self

def _end_suite ( self , name , attrs ):

imprime 'Suite % s ( % s ) se terminant.' % ( name , attrs [
'id' ])

# code de la bibliothèque actuelle ici ...

Comme le montre l'exemple ci-dessus, les auditeurs de bibliothèque doivent

spécifier des versions d'interface d'écouteur utilisant
l' ROBOT_LISTENER_API_VERSION attribut exactement comme n'importe quel autre
écouteur.

À partir de la version 2.9, vous pouvez également fournir n'importe quelle liste
comme objet d'instance dans l' ROBOT_LIBRARY_LISTENERattribut. Cela entraînera
l'enregistrement de toutes les instances de la liste en tant qu'écouteurs.

Appelé les méthodes d'écoute

L'écouteur de la bibliothèque recevra des notifications sur tous les événements dans
les suites où la bibliothèque est importée. En pratique , cela signifie
que start_suite, end_suite, start_test, end_test, start_keyword, end_keyword, log
_messageet les messageméthodes sont appelées à l' intérieur de ces suites.

Si la bibliothèque crée une nouvelle instance d'écouteur chaque fois que la

bibliothèque elle-même est instanciée, l'instance d'écouteur réelle à utiliser change
en fonction de l' étendue de la bibliothèque de tests . Outre les méthodes d'écoute
précédemment répertoriées, la close méthode est appelée lorsque la bibliothèque
sort de la portée.

Voir la section Méthodes d'interface d'écoute ci-dessus pour plus d'informations sur
toutes ces méthodes.

4.4 Extension du pot du cadre robot

L'ajout de bibliothèques de test ou de code de support supplémentaires au fichier
Jar du Framework Robot est assez simple en utilisant la commande jar incluse
dans l'installation standard du JDK. Le code Python doit être placé dans
le répertoire Lib à l'intérieur du fichier jar et le code Java peut être placé
directement à la racine du fichier jar, en fonction de la structure du package.

Par exemple, pour ajouter un package Python mytestlibau fichier JAR , copiez
d'abord le répertoire mytestlib sous un répertoire appelé Lib , puis exécutez la
commande suivante dans le répertoire contenant Lib :
jar uf /path/to/robotframework-2.7.1.jar Lib

Pour ajouter des classes Java compilées au fichier jar, vous devez avoir une
structure de répertoires correspondant à la structure du package Java et l'ajouter
récursivement au fichier zip.

Par exemple, pour ajouter la classe MyLib.class, dans le package org.test, le

fichier doit être dans org / test / MyLib.class et vous pouvez exécuter:
jar uf /path/to/robotframework-2.7.1.jar org

5 outils de support
 5.1 Outil de documentation de la bibliothèque (Libdoc)
 5.2 Outil de documentation des données de test (Testdoc)
 5.3 Outil de nettoyage des données de test (Tidy)
 5.4 Outils externes

5.1 Outil de documentation de la bibliothèque

(Libdoc)
 5.1.1 Usage général
 5.1.2 Rédaction de la documentation
 5.1.3 Syntaxe de la documentation
 5.1.4 Liaison interne
 5.1.5 Représentation des arguments
 5.1.6 Exemple Libdoc

Libdoc est l'outil intégré de Robot Framework pour générer de la documentation

sur les mots clés pour les bibliothèques de tests et les fichiers de ressources aux
formats HTML et XML. L'ancien format convient aux humains et le second
aux outils RIDE et autres. Libdoc a également quelques commandes spéciales pour
afficher des informations sur les bibliothèques ou les ressources sur la console.

La documentation peut être créée pour:

 tester les bibliothèques implémentées avec Python ou Java en utilisant l'API

de bibliothèque statique normale,
  tester les bibliothèques à l'aide de l' API dynamique , y compris les
bibliothèques distantes, et
 fichiers de ressources .

De plus, il est possible d'utiliser des spécifications XML créées par Libdoc plus tôt
en tant qu'entrée.

5.1.1 Usage général

Synopsis
python -m robot.libdoc [options] library_or_resource fichier_sortie
python -m robot.libdoc [options] liste library_or_resource | show |
version [noms]

Les options

-f, --format <html|xml>

Spécifie s'il faut générer une sortie HTML ou XML. Si cette option n'est pas
utilisée, le format provient de l'extension du fichier de sortie.

-F, --docformat <robot|html|text|rest>

Spécifie le format de la documentation source. Les valeurs possibles sont le

format de documentation de Robot Framework, HTML, texte brut et
reStructuredText. La valeur par défaut peut être spécifiée dans le code source de
la bibliothèque de tests et la valeur par défaut initiale est robot. Nouveau dans
Robot Framework 2.7.5.

-N, --name <newname>

Définit le nom de la bibliothèque ou de la ressource documentée.

-V, --version <newversion>

Définit la version de la bibliothèque ou de la ressource documentée. La valeur

par défaut des bibliothèques de tests provient du code source .

-P, --pythonpath <path>

Emplacements supplémentaires où rechercher des bibliothèques et des ressources

de la même manière que lors de l' exécution de tests .

-E, --escape <what:with>

 Échappe aux caractères problématiques dans la console. whatest le nom du
personnage à échapper et withest la chaîne avec laquelle il doit s'échapper. Les
échappements disponibles sont répertoriés dans la sortie --help .

-h, - Imprime cette aide.

-help

Exécution alternative
Bien que Libdoc ne soit utilisé qu'avec Python dans le synopsis ci-dessus, il
fonctionne également avec Jython et IronPython. Lorsque vous documentez des
bibliothèques Java, Jython est réellement requis.

Dans le synopsis, Libdoc est exécuté en tant que module installé ( python -m
robot.libdoc). En plus de cela, il peut être exécuté aussi en tant que script:

arguments python path / robot / libdoc.py [options]

L'exécution en tant que script peut être utile si vous avez effectué une installation
manuelle ou avez simplement le répertoire du robot avec le code source quelque part
dans votre système.

Spécification du fichier de bibliothèque ou de ressource

Bibliothèques Python et bibliothèques dynamiques avec nom ou chemin

Lorsque vous documentez des bibliothèques implémentées avec Python ou qui

utilisent l' API de bibliothèque dynamique , il est possible de spécifier la bibliothèque
en utilisant uniquement le nom de la bibliothèque ou le chemin d'accès au code
source de la bibliothèque. Dans le premier cas, la bibliothèque est recherchée à
l'aide du chemin de recherche du module et son nom doit avoir le même format que
dans les données de test de Robot Framework.

Si ces bibliothèques requièrent des arguments lorsqu'elles sont importées, les

arguments doivent être regroupés avec le nom de la bibliothèque ou le chemin
d'accès en utilisant deux virgules commeMyLibrary::arg1::arg2. Si les arguments
modifient les mots-clés fournis par la bibliothèque ou modifient autrement sa
documentation, il peut être judicieux d'utiliser l' option --name pour modifier le
nom de la bibliothèque en conséquence.

Bibliothèques Java avec chemin

Une bibliothèque de test Java implémentée à l'aide de l' API de bibliothèque

statique peut être spécifiée en attribuant le chemin au fichier de code source
contenant l'implémentation de la bibliothèque. De plus, tools.jar , qui fait partie de
la distribution Java JDK, doit être trouvé à partir de CLASSPATH lorsque Libdoc est
exécuté. Notez que la génération de documentation pour les bibliothèques Java ne
fonctionne qu'avec Jython.

Fichiers de ressources avec chemin

Les fichiers de ressources doivent toujours être spécifiés à l'aide d'un chemin. Si le
chemin n'existe pas, les fichiers de ressources sont également recherchés de la
même manière dans tous les répertoires du chemin de recherche du module que lors de
l'exécution de scénarios de test.

Génération de documentation
Lors de la génération de la documentation au format HTML ou XML, le fichier de
sortie doit être spécifié comme second argument après le nom ou le chemin de la
bibliothèque / ressource. Le format de sortie est obtenu automatiquement à partir de
l'extension mais peut également être défini à l'aide de l' option --format .

Exemples:
python -m robot.libdoc OperatingSystem OperatingSystem.html
python -m robot.libdoc --name MyLibrary Remote :: http: //10.0.0.42:
8270 MyLibrary.xml
python -m robot.libdoc test / resource.html doc / resource_doc.html
jython -m robot.libdoc --version 1.0 MyJavaLibrary.java
MyJavaLibrary.html
jython -m robot.libdoc my.organization.DynamicJavaLibrary
my.organization.DynamicJavaLibrary.xml

Affichage des informations sur la console

Libdoc dispose de trois commandes spéciales pour afficher des informations sur la
console. Ces commandes sont utilisées à la place du nom du fichier de sortie et
elles peuvent également prendre des arguments supplémentaires.
list
Répertorie les noms des mots-clés que contient la bibliothèque /
ressource. Peut être limité à afficher uniquement certains mots-clés en
transmettant des modèles facultatifs comme arguments. Le mot clé est
répertorié si son nom contient un modèle donné.
show
Afficher la documentation de la bibliothèque / ressource. Peut être limité à
afficher uniquement certains mots-clés en passant des noms comme
arguments. Le mot-clé est affiché si son nom correspond à un nom
donné. Un argument spécial introaffichera uniquement les sections
d'introduction et d'importation de la bibliothèque.
version
 Afficher la version de la bibliothèque

Modèles facultatifs donnés à listet showsont peu sensibles cas et dans

l' espace. Les deux acceptent également *et ?comme jokers.

Exemples:
Liste de boîtes de dialogue python -m robot.libdoc
python -m robot.libdoc SeleniumLibrary navigateur de liste
python -m robot.libdoc Remote :: 10.0.0.42: 8270
python -m robot.libdoc Les boîtes de dialogue montrent PauseExecution
exécutée *
python -m robot.libdoc SeleniumLibrary show intro
python -m robot.libdoc Version SeleniumLibrary

5.1.2 Rédaction de la documentation

Cette section traite de l'écriture de documentation pour les bibliothèques de test
basées sur Python et Java qui utilisent l'API de bibliothèque statique, ainsi que
pour les bibliothèques dynamiques et les fichiers de ressources . La création de bibliothèques
de tests et de fichiers de ressources est décrite plus en détail ailleurs dans le Guide de
l'utilisateur.

Bibliothèques Python
La documentation des bibliothèques Python qui utilisent l' API de la bibliothèque
statique est simplement écrite en tant que chaînes de doc pour la classe ou le module
de bibliothèque et pour les méthodes implémentant des mots-clés. La première
ligne de la documentation de la méthode est considérée comme une courte
documentation pour le mot-clé (utilisée par exemple comme une info-bulle dans les
liens de la documentation HTML générée) et devrait donc être aussi descriptive que
possible, mais pas trop longue.

L'exemple simple ci-dessous montre comment écrire la documentation en général,

et il y a un exemple un peu plus long à la fin de ce chapitre contenant également un
exemple de la documentation générée.
class ExampleLib :
"" "Bibliothèque à des fins de démonstration.

Cette bibliothèque est uniquement utilisée dans un exemple et ne fait

rien d’utile.
"" "

def my_keyword ( self ):

"" Ne fait rien. "" "
passe

def your_keyword ( self , arg ):

"" Prend un argument et * ne fait rien *.
 Exemples:
| Votre mot clé | xxx |
| Votre mot clé | yyy |
"" "
passe

Pointe

Si vous voulez utiliser des caractères non-ASCII dans la documentation des bibliothèques
Python, vous devez soit utiliser UTF-8 comme encodage de votre code source, soit créer des
docstrings comme Unicode.

Pour plus d'informations sur les chaînes de documentation Python, voir PEP-257 .

Bibliothèques Java
La documentation des bibliothèques Java utilisant l' API de bibliothèque statique est
écrite en tant que commentaires Javadoc normaux pour la classe et les méthodes de la
bibliothèque. Dans ce cas, Libdoc utilise réellement l’outil Javadoc en interne et
donc tools.jar le contenant doit être dans CLASSPATH . Ce fichier jar fait partie de la
distribution Java SDK normale et doit être trouvé dans le répertoire bin sous
l’installation du SDK Java.

L'exemple simple suivant possède exactement la même documentation (et la même

fonctionnalité) que l'exemple Python précédent.
/ **
* Bibliothèque à des fins de démonstration.
*
* Cette bibliothèque est uniquement utilisée dans un exemple et ne fait
rien d’utile.
* /
classe publique ExampleLib {

/ **
* Ne fait rien.
* /
public void myKeyword () {
}

/ **
* Prend un argument et * ne fait rien *.
*
* Exemples:
* | Votre mot clé | xxx |
* | Votre mot clé | yyy |
* /
Publique vide yourKeyword ( chaîne arg ) {
}
}

Bibliothèques dynamiques
Pour être en mesure de générer des documents significatifs pour les bibliothèques
dynamiques, les bibliothèques doivent retourner les noms d'argument mot - clé et
la documentation à
l' aideget_keyword_argumentset get_keyword_documentation méthodes (ou
en utilisant leurs variantes
camelCase getKeywordArguments et getKeywordDocumentation). Les bibliothèques
peuvent également prendre en charge la documentation générale de la bibliothèque
via special __intro__et des __init__valeurs à
la get_keyword_documentationméthode.

Consultez la section API de bibliothèque dynamique pour plus d'informations sur la

création de ces méthodes.

Section d'importation
Une section distincte sur la façon dont la bibliothèque est importée est créée en
fonction de ses méthodes d'initialisation. Pour une bibliothèque Python, si elle
possède une __init__ méthode qui prend des arguments en plus self, sa
documentation et ses arguments sont affichés. Pour une bibliothèque Java, si elle a
un constructeur public qui accepte les arguments, tous ses constructeurs publics
sont affichés.
classe TestLibrary :

def __init__ ( self , mode = 'default' )

"" "Crée un nouveau TestLibrary. L'argument` mode` est utilisé pour
déterminer le mode. "" "
self . mode = mode

def some_keyword ( self , arg ):

"" "Fait quelque chose basé sur` arg` donné.

Ce qui est fait dépend du mode spécifié lors de l'importation de la

bibliothèque.
"" »
Si l' auto . En mode == 'secret' :
# ...

Documentation du fichier de ressources

Les mots-clés dans les fichiers de ressources peuvent avoir de la documentation en
utilisant le paramètre [Documentation] , et cette documentation est également
utilisée par Libdoc. La première ligne de la documentation (jusqu'à la
première ligne implicite ou explicite \n) est considérée comme la courte
documentation de la même manière qu'avec les bibliothèques de test.

De plus, le fichier de ressources lui-même peut contenir de la documentation dans

le tableau Paramètres pour documenter l'intégralité du fichier de ressources.
Les variables possibles dans les fichiers de ressources ne peuvent pas être
documentées.
*** Paramètres ***
Documentation Ressource fichier à des fins de démonstration.
... Cette ressource n'est utilisée que dans un exemple et ne
fait rien d'utile.

*** Mots clés ***

Mon mot clé
[ Documentation ] Ne fait rien
Pas d'opération

Votre mot-clé
[ Arguments ] $ { arg }
[ Documentation ] Prend un argument et * ne fait rien *.
...
... Exemples:
... | Votre mot clé | xxx |
... | Votre mot clé | yyy |
Pas d'opération

5.1.3 Syntaxe de la documentation

Libdoc prend en charge la documentation dans la syntaxe de la documentation de
Robot Framework , HTML, texte brut et reStructuredText . Le format à utiliser peut
être spécifié dans le code source de la bibliothèque de tests à l' aide de
l' ROBOT_LIBRARY_DOC_FORMAT attribut ou à partir de la ligne de commande en
utilisant l' option --docformat (-F) . Dans les deux cas, les valeurs
insensibles à la casse possibles sont ROBOT(par défaut) HTML, TEXTet reST.

Le format de documentation propre à Robot Framework est le format par défaut et

généralement recommandé. D'autres formats sont particulièrement utiles lorsque
vous utilisez du code existant avec de la documentation existante dans des
bibliothèques de test. La prise en charge d'autres formats a été ajoutée dans Robot
Framework 2.7.5.

Syntaxe de la documentation sur la structure du robot

Les fonctionnalités les plus importantes de la syntaxe de documentation de Robot
Framework sont le formatage à l'aide de *bold*et _italic_, les liens personnalisés
et la conversion automatique des URL en liens, et la possibilité de créer des
tableaux et des blocs de texte préformatés Si la documentation s'allonge, la prise en
charge des titres de section (nouveaux dans Robot Framework 2.7.5) peut
également être utile.

Certaines des fonctionnalités de formatage les plus importantes sont illustrées dans
l'exemple ci-dessous. Notez que comme il s'agit du format par défaut, il n'est pas
nécessaire d'utiliser l'ROBOT_LIBRARY_DOC_FORMATattribut ni de donner le format à
partir de la ligne de commande.
"" "Exemple de bibliothèque au format Robot Framework.

- Formatage avec * bold * et _italic_.

- Les URL telles que http://example.com sont converties en liens.
- Les liens personnalisés comme [http: //robotframework.org | Robot
Framework] sont pris en charge.
- Lier à `My Keyword` fonctionne.
"" "

def my_keyword ():

"" Rien de plus à voir ici. "" "

Syntaxe de la documentation HTML

En utilisant le format HTML, vous pouvez créer de la documentation à peu près
librement en utilisant n'importe quelle syntaxe. L'inconvénient principal est que le
balisage HTML n'est pas aussi convivial que possible et que la documentation du
code source est difficile à gérer et à lire. La documentation au format HTML est
utilisée par Libdoc directement sans aucune transformation ou échappement. La
syntaxe spéciale pour lier des mots-clés en utilisant une syntaxe comme `My
Keyword` est cependant supportée.

L'exemple ci-dessous contient les mêmes exemples de format que l'exemple

précédent. Maintenant, l' ROBOT_LIBRARY_DOC_FORMATattribut doit être utilisé ou le
format indiqué sur la ligne de commande --docformat HTML.
"" "Exemple de bibliothèque au format HTML.

<ul>
<li> Mise en forme avec <b> gras </ b> et <i> italique </ i>.
<li> Les URL ne sont pas automatiquement converties en liens.
<li> Les liens personnalisés tels que <a href="http://www.w3.org/html">
HTML </a> sont pris en charge.
<li> Lier à `My Keyword` fonctionne.
</ ul>
"" "
ROBOT_LIBRARY_DOC_FORMAT = 'HTML'

def my_keyword ():

"" Rien de plus à voir ici. "" "

Syntaxe de la documentation en texte brut

Lorsque le format de texte brut est utilisé, Libdoc utilise la documentation telle
quelle. Les nouvelles lignes et les autres espaces sont conservés, sauf pour
l'indentation, et les caractères spéciaux HTML ( <>&) ont été supprimés. Le seul
formatage effectué consiste à transformer les URL en liens cliquables et à prendre
en charge les liaisons internes telles que «My Keyword» .
"" "Exemple de bibliothèque au format texte brut.

- Le formatage n'est pas pris en charge.

- Les URL telles que http://example.com sont converties en liens.
- Les liens personnalisés ne sont pas pris en charge.
- Lier à `My Keyword` fonctionne.
"" "
ROBOT_LIBRARY_DOC_FORMAT = 'texte'

def my_keyword ():

"" Rien de plus à voir ici. "" "

Syntaxe de la documentation reStructuredText

reStructuredText est une syntaxe de balisage simple mais puissante utilisée largement
dans les projets Python (y compris ce Guide de l'utilisateur) et ailleurs. La
principale limitation est que vous devez avoir le module docutils installé pour
pouvoir générer de la documentation en l’utilisant. Parce que les caractères
backtick ont une signification particulière dans reStructuredText, la liaison aux mots-
clés exige qu'ils soient échappés comme \ `My Keyword \` .

L'une des fonctionnalités intéressantes des supports reStructured est la possibilité

de marquer les blocs de code pouvant être mis en évidence par la syntaxe. La
syntaxe du bloc de code a toujours fonctionné avec Robot Framework, mais ils ne
sont mis en évidence que dans RF 3.0.1 et versions ultérieures. La mise en évidence
de la syntaxe nécessite un module Pygments supplémentaire et prend en charge
toutes les langues prises en charge par Pygments.
"" "Exemple de bibliothèque au format reStructuredText.

- Formatage avec ** gras ** et * italique *.

- Les URL telles que http://example.com sont converties en liens.
- Les liens personnalisés comme reStructuredText__ sont pris en charge.
- La liaison à \ `My Keyword \` fonctionne mais nécessite que les backtics
soient échappés.

__ http://docutils.sourceforge.net

.. code :: robotframework

*** Cas de test ***

Exemple
Mon mot-clé # Comme c'est cool !!? !!?! 1 !!
"" "
ROBOT_LIBRARY_DOC_FORMAT = 'reST'

def my_keyword ():

"" Rien de plus à voir ici. "" "

5.1.4 Liaison interne

Libdoc prend en charge les liens internes vers des mots-clés et différentes sections
de la documentation. La liaison se fait en entourant le nom de la cible avec des
caractères backtick comme `target` . Les noms de cible ne sont pas sensibles à
la casse et les cibles possibles sont expliquées dans les sections suivantes.

Il n'y a pas d'erreur ou d'avertissement si une cible de lien n'est pas trouvée, mais à
la place, Libdoc formate simplement le texte en italique. Auparavant, il était
recommandé d’utiliser cette mise en forme lorsqu’on faisait référence à des
arguments de mot-clé, mais cela posait problème car cela risquait de créer
accidentellement des liens internes. Aujourd'hui, il est recommandé d'utiliser
un style de code en ligne avec des raccourcis doubles tels que ``
argument`` . L'ancien formatage des raccourcis uniques peut même être
supprimé à l'avenir en faveur d'une erreur lorsqu'une cible de lien n'est pas trouvée.

Outre les exemples des sections suivantes, les liaisons internes et la mise en forme
des arguments sont également présentées dans l’ exemple le plus long à la fin de ce
chapitre.

Liaison à des mots-clés

Tous les mots-clés de la bibliothèque créent automatiquement des cibles de lien et
peuvent être liés à l'aide de la syntaxe «Nom du mot-clé» . Ceci est illustré par
l'exemple ci-dessous où les deux mots-clés ont des liens entre eux.
mot-clé def ( log_level = "INFO" ):
"" "Fait quelque chose et enregistre la sortie en utilisant le niveau
donné.

Les valeurs valides pour le niveau de journalisation sont "INFO" (par

défaut) "DEBUG" et "TRACE".

Voir aussi `Another Keyword`.

"" "
# ...

def another_keyword ( argument , log_level = "INFO" ):

"" "Fait quelque chose avec l'argument donné et enregistre la sortie.

Voir `Keyword` pour plus d’informations sur les niveaux de journal

valides.
"" "
# ...

Remarque

Lors de l'utilisation de la syntaxe de la documentation reStructuredText , les backticks doivent

être échappés comme \ `Nom du mot-clé \` .

Liaison aux sections automatiques

La documentation générée par Libdoc contient toujours des sections pour
l’introduction générale de la bibliothèque, des raccourcis vers des mots-clés et des
mots-clés réels. Si une bibliothèque elle-même prend des arguments, il existe
également une section d'importation distincte .

Toutes ces sections agissent comme des cibles pouvant être liées et les noms de
cibles possibles sont répertoriés dans le tableau ci-dessous. L'utilisation de ces
cibles est illustrée dans l'exemple de la section suivante.

Cibles de lien de section automatique

Section Cible

introduction `introduction` et ` bibliothèque introduction`

Importer `importing` et ` bibliothèque importing`

Raccourcis `raccourcis` (Nouveau dans Robot Framework 2.7.5.)

Mots clés `keywords` (Nouveau dans Robot Framework 2.7.5.)

Liaison à des sections personnalisées

À partir de la version 2.7.5, la syntaxe de la documentation de Robot Framework prend
en charge les titres de section personnalisés , et les titres utilisés dans la bibliothèque
ou l'introduction du fichier de ressources créent automatiquement des cibles de
liens. L'exemple ci-dessous illustre la liaison entre les sections automatique et
personnalisée:
"" "Bibliothèque à des fins de démonstration.

Cette bibliothèque ne fait rien d’utile.

= Ma section =

Nous avons cependant une section personnalisée dans la documentation.

"" "

def mot-clé ():

"" Ne fait rien.

Voir `introduction` pour plus d’informations et` Ma section` pour

tester le fonctionnement de la
liaison aux sections personnalisées.
"" "
passe

Remarque

La liaison à des sections personnalisées ne fonctionne que lors de l'utilisation de la syntaxe de

documentation de Robot Framework .

Remarque
Avant Robot Framework 2.8, seuls les titres de section de premier niveau pouvaient être liés.

5.1.5 Représentation des arguments

Libdoc gère automatiquement les arguments des mots clés afin que les arguments
spécifiés pour les méthodes dans les bibliothèques ou les mots clés utilisateur dans
les fichiers de ressources soient répertoriés dans une colonne distincte. Les
arguments de mot-clé utilisateur sont affichés sans ${}ou @{}pour que les
arguments aient la même apparence, peu importe d'où proviennent les mots-clés.

Indépendamment de la manière dont les mots-clés sont réellement implémentés,

Libdoc affiche des arguments similaires à ceux utilisés lors de la création de mots-
clés en Python. Cette mise en forme est expliquée plus en détail dans le tableau ci-
dessous.

Comment Libdoc représente les arguments

Arguments Maintenant représenté Exemples

Aucun argument Colonne vide

one_argument
Un ou plusieurs arguments Liste de chaînes contenant des noms
d'argument. a1, a2, a3

arg=default
Valeurs par défaut pour les Les valeurs par défaut sont séparées des
value
arguments noms par =.
a, b=1, c=2

*varargs
Nombre variable Le dernier argument (ou le dernier avec
d'arguments (varargs) kwargs) a * avant son nom. a, b=42, *rest

**kwargs
Arguments de mots clés Les derniers arguments ont **avant son
gratuits (kwargs) nom. a, b=42, **kws
*varargs,
**kwargs

Lorsque vous faites référence à des arguments dans la documentation de mots-clés,

il est recommandé d'utiliser un style de code en ligne tel que "argument" .

5.1.6 Exemple Libdoc

L'exemple suivant illustre comment utiliser les possibilités de formatage de la
documentation les plus importantes , les liaisons internes , etc. Cliquez ici pour voir à
quoi ressemble la documentation générée.
class LoggingLibrary :
"" "Bibliothèque pour la journalisation des messages.

= Table des matières =

 - `Usage` -`
Niveaux de journal valides`
- `Examples`
-` Importing`
- `Shortcuts`
-` Keywords`

= Utilisation =

Cette bibliothèque a plusieurs mots-clés, par exemple «Message de

journal», pour la journalisation des
messages. En réalité, la bibliothèque est utilisée uniquement à des
fins de démonstration _Libdoc_ .

= Niveaux de journal valides =

Les niveaux de journal valides sont `` INFO``, `` DEBUG`` et ``

TRACE``. Le
niveau de journalisation par défaut peut être défini lors de
l'importation.

= Exemples =

Notez comment les mots-clés sont liés à partir d'exemples.

| `Message de journal` | Mon message | | |

| `Log Two Messages` | Mon message | Deuxième message level = DEBUG |
| `Messages de connexion` | Premier message | Deuxième message |
Troisième message |
"" "
ROBOT_LIBRARY_VERSION = '0.1'

def __init__ ( self , default_level = 'INFO' ):

"" Le niveau de journalisation par défaut peut être donné au moment
de l'importation de la bibliothèque.

Voir la section `Niveaux de journal valides` pour plus

d'informations sur les
niveaux de journalisation disponibles .

Exemples:

| = Réglage = | = Valeur = | = Valeur = | = Comment = |

| Bibliothèque | LoggingLibrary | | # Utiliser le niveau par défaut
(INFO) |
| Bibliothèque | LoggingLibrary | DEBUG | # Utiliser le niveau
donné |
"" "
self . default_level = self . _verify_level ( default_level )

def _verify_level ( self , level ):

level = level . upper ()
si level pas dans [ 'INFO' , 'DEBUG' , 'TRACE' ]:
raise RuntimeError ( "Niveau de log invalide ' % s '. Les
niveaux valides sont"
"'INFO', 'DEBUG' et 'TRACE' " )
niveau de retour

def log_message ( self , message , level = None ):

 "" Écrit le message donné dans le fichier journal en utilisant le
niveau de journal spécifié.

Le message à consigner et le niveau de

consignation à utiliser sont définis en utilisant respectivement
les arguments `` message`` et `` level``.

Si aucun niveau de journalisation n'est donné, le niveau par défaut

donné lors de `
importation de
bibliothèque ' est utilisé. "" "
level = self . _verify_level ( level ) si level else self .
default_level
print " * % s * % s " % ( niveau , message )

def log_two_messages ( auto , message1 , message2 , niveau = Aucun

):
« » "écrit des messages donnés dans le fichier journal en utilisant
le niveau de journal spécifié.

Voir le mot clé `Message de journal` pour plus d'informations.

"" »
Auto . Log_message ( message1 , niveau )
auto . Log_message ( message2 , niveau )

deflog_messages ( self , * messages ):

"" "Journalise les messages donnés en utilisant le niveau de
journalisation défini lors de l'importation.

Voir aussi `Message de log` et` Log Two Messages`.

"" "
pour msg dans les messages :
self . log_message ( msg )

Toutes les bibliothèques standard disposent de la documentation générée par Libdoc et

leur documentation (et leur code source) constitue un exemple plus réaliste.

5.2 Outil de documentation des données de test

(Testdoc)
 5.2.1 Usage général
 5.2.2 Génération de la documentation

Testdoc est l'outil intégré de Robot Framework pour générer une documentation de
haut niveau basée sur des cas de test. La documentation créée est au format HTML
et comprend le nom, la documentation et les autres métadonnées de chaque suite de
tests et cas de test, ainsi que les mots-clés de niveau supérieur et leurs arguments.

5.2.1 Usage général

Synopsis
python -m robot.testdoc [options] data_sources fichier_sortie
Les options

-T, --title <title>

Définissez le titre de la documentation générée. Les traits de soulignement dans

le titre sont convertis en espaces. Le titre par défaut est le nom de la suite de
niveau supérieur.

-N, --name <name>

Remplacez le nom de la suite de tests de niveau supérieur.

-D, --doc <doc>

Remplacez la documentation de la suite de tests de niveau supérieur.

-M, --metadata <name:value>

Définir / remplacer les métadonnées gratuites de la suite de tests de niveau

supérieur.

-G, --settag <tag>

Définir les balises données à tous les cas de test.

-t, --test <name>

Inclure les tests par nom.

-s, --suite <name>

Inclure les suites par nom.

-i, --include <tag>

Inclure les tests par balises.

-e, --exclude <tag>

Exclure les tests par balises.

-A, --argumentfile <path>

Fichier texte pour lire plus d'arguments à partir de. Fonctionne exactement
comme des fichiers d'argument lors de l'exécution de tests. Nouveau dans
Robot Framework 3.0.2.

-h, -- Imprimez cette aide dans la console.

help
Toutes les options, à l'exception de --title, ont exactement la même
sémantique que les mêmes options lors de l' exécution de cas de test .

5.2.2 Génération de la documentation

Les données peuvent être données sous la forme d'un fichier unique, d'un répertoire
ou de plusieurs fichiers et répertoires. Dans tous ces cas, le dernier argument doit
être le fichier où écrire la sortie.

Testdoc fonctionne avec tous les interpréteurs pris en charge par Robot Framework
(Python, Jython et IronPython). Il peut être exécuté comme un module installé
comme python -m robot.testdocou comme un script python
path/robot/testdoc.py.

Exemples:
python -m robot.testdoc my_test.html testdoc.html
jython -m robot.testdoc --name smoke_tests --include chemin de fumée /
to / my_tests smoke.html
chemin ipy / vers / robot / testdoc.py first_suite.txt
second_suite.txt output.html

5.3 Outil de nettoyage des données de test (Tidy)

 5.3.1 Usage général
 5.3.2 Nettoyage des données de test
 5.3.3 Modification du format des données de test

Tidy est un outil intégré à Robot Framework pour le nettoyage et la modification

du format des fichiers de données de test de Robot Framework.

La sortie est écrite dans le flux de sortie standard par défaut, mais un fichier de
sortie facultatif peut être donné à partir de Robot Framework 2.7.5. Les fichiers
peuvent également être modifiés sur place à l'aide des options --inplace ou --
recursive .

5.3.1 Usage général

Synopsis
python -m robot.tidy [options] fichier entrée
python -m robot.tidy [options] fichier d'entrée [fichier de sortie]
python -m robot.tidy --inplace [options] inputfile [plus de fichiers
d'entrée]
répertoire python -m robot.tidy --recursive [options]

Les options
 -i, -- Rangez les fichiers pour que les fichiers originaux soient écrasés (ou
inplace supprimés si le format est modifié). Lorsque cette option est utilisée, il est
possible de donner plusieurs fichiers d'entrée. Exemples:

python -m robot.tidy --inplace testss.html

python -m robot.tidy --inplace --format txt * .html
-r, --recursive
Traiter le répertoire donné de manière récursive. Les fichiers du répertoire
sont traités de la même manière que lorsque l' option --inplace est
utilisée.
-f, --format <robot|txt|html|tsv>
Format de fichier de sortie. Si le fichier de sortie est donné explicitement, la
valeur par défaut provient de son extension. Sinon, le format n'est pas
modifié.
-p, --use-pipes
Utilisez un caractère de canal (|) comme séparateur de cellules au format
txt.
-s, --spacecount <number>
Le nombre d'espaces entre les cellules au format txt. Nouveau dans Robot
Framework 2.7.3.
-l, --lineseparator <native|windows|unix>
Séparateur de ligne à utiliser dans les sorties. La valeur par défaut est
«native».

 native : utilise les séparateurs de ligne natifs du système

d'exploitation
 windows : utilisez les séparateurs de ligne Windows (CRLF)
 unix : utilise les séparateurs de lignes Unix (LF)

Nouveau dans Robot Framework 2.7.6.

-h, -- Montrer cette aide
help

Exécution alternative
Bien que Tidy ne soit utilisé qu'avec Python dans le synopsis ci-dessus, il
fonctionne également avec Jython et IronPython. Dans le synopsis, Tidy est
exécuté en tant que module installé ( python -m robot.tidy), mais il peut
également être exécuté en tant que script:
arguments python path / robot / tidy.py [options]

L'exécution en tant que script peut être utile si vous avez effectué une installation
manuelle ou avez simplement le répertoire du robot avec le code source quelque part
dans votre système.

Encodage de sortie
Tous les fichiers de sortie sont écrits en utilisant le codage UTF-8. Les sorties
écrites sur la console utilisent le codage de la console en cours.

5.3.2 Nettoyage des données de test

Les fichiers de cas de test créés avec les éditeurs HTML ou écrits à la main peuvent
être normalisés à l'aide de Tidy. Tidy écrit toujours des en-têtes cohérents, un ordre
cohérent pour les paramètres et une quantité cohérente d'espaces blancs entre les
cellules et les tables.

Exemples:
python -m robot.tidy messed_up_tests.html cleaning_tests.html
python -m robot.tidy --inplace tests.txt

5.3.3 Modification du format des données de test

Robot Framework prend en charge les données de test aux formats HTML, TSV et
TXT et Tidy facilite la modification des formats. Le format d'entrée est toujours
déterminé en fonction de l'extension du fichier d'entrée. Le format de sortie peut
être défini à l'aide de l' option --format , et la valeur par défaut provient de
l'extension du fichier de sortie possible.

Exemples:
python -m robot.tidy tests.html tests.txt
python -m robot.tidy --format txt --inplace tests.html
python -m robot.tidy --format tsv --cursifs récursifs

5.4 Outils externes

De nombreux outils externes peuvent être utilisés avec Robot Framework. Ces
outils incluent l'éditeur de données de test RIDE , des extensions pour divers IDE et
des éditeurs de texte, des plug-ins pour des systèmes d'intégration continue et des
outils de génération, etc.

Ces outils sont développés en tant que projets distincts indépendamment de Robot
Framework lui-même. Pour une liste des outils disponibles,
voir http://robotframework.org/#tools .

Remarque

Certains outils de support étaient distribués avec Robot Framework lui-même. De nos jours,
tous ces outils sont également disponibles séparément et ont été supprimés du référentiel et de
la distribution source dans Robot Framework 2.8.6.
6 annexes
 6.1 Tous les paramètres disponibles dans les données de test
 6.2 Toutes les options de ligne de commande
 6.3 Modèles de données de test
 6.4 Formatage de la documentation
 6.5 Format de l'heure
 6.6 Arguments booléens
 6.7 API interne

6.1 Tous les paramètres disponibles dans les

données de test
 6.1.1 Table de réglage
 6.1.2 Table de test case
 6.1.3 Tableau des mots clés

6.1.1 Table de réglage

La table Setting permet d'importer des bibliothèques de tests, des fichiers de
ressources et des fichiers de variables et de définir des métadonnées pour les suites
de tests et les cas de test. Il peut être inclus dans les fichiers de scénarios de test et
les fichiers de ressources. Notez que dans un fichier de ressources, un tableau
Paramètres ne peut inclure que des paramètres d'importation de bibliothèques, de
ressources et de variables.

Paramètres disponibles dans le tableau des paramètres

prénom La description

Bibliothèque Utilisé pour importer des bibliothèques .

Ressource Utilisé pour utiliser des fichiers de ressources .

Les variables Utilisé pour utiliser des fichiers variables .

Documentation Utilisé pour spécifier une suite de tests ou une documentation de fichier
de ressources .

Métadonnées Utilisé pour définir des métadonnées de suite de tests gratuites .

Configuration de la Utilisé pour spécifier la configuration de la suite .

suite

Suite Teardown Utilisé pour spécifier le démontage de la suite .

Balises de force Utilisé pour spécifier des valeurs forcées pour les balises lors du balisage
des cas de test .
 Paramètres disponibles dans le tableau des paramètres

prénom La description

Balises par défaut Utilisé pour spécifier des valeurs par défaut pour les balises lors
du balisage des cas de test.

Configuration du test Utilisé pour spécifier une configuration de test par défaut .

Test Teardown Utilisé pour spécifier un démontage de test par défaut .

Modèle de test Utilisé pour spécifier un mot clé de modèle par défaut pour les
scénarios de test.

Délai de test Utilisé pour spécifier un délai d'expiration de test élémentaire .

Remarque

Tous les noms des paramètres peuvent éventuellement inclure deux points à la fin, par
exemple Documentation: . Cela peut faciliter la lecture des paramètres, en particulier lorsque
vous utilisez le format texte brut.

6.1.2 Table de test case

Les paramètres de la table Test Case sont toujours spécifiques au scénario de test
pour lequel ils sont définis. Certains de ces paramètres remplacent les valeurs par
défaut définies dans le tableau Paramètres.

Paramètres disponibles dans le tableau Test Case

prénom La description

[Documentation] Utilisé pour spécifier une documentation de scénario de test .

[Mots clés] Utilisé pour le marquage des cas de test .

[Installer] Utilisé pour spécifier une configuration de test .

[Abattre] Utilisé pour spécifier un démontage de test .

[Modèle] Utilisé pour spécifier un mot clé de modèle .

[Temps libre] Utilisé pour spécifier un délai d'expiration de test élémentaire.

6.1.3 Tableau des mots clés

Les paramètres du tableau Mot-clé sont spécifiques au mot-clé utilisateur pour
lequel ils sont définis.
 Paramètres disponibles dans le tableau des mots clés

prénom La description

[Documentation] Utilisé pour spécifier une documentation de mot-clé utilisateur .

[Mots clés] Utilisé pour spécifier les étiquettes de mots-clés utilisateur .

[Arguments] Utilisé pour spécifier les arguments de mot-clé utilisateur .

[Revenir] Utilisé pour spécifier les valeurs de retour de mot-clé utilisateur .

[Abattre] Utilisé pour spécifier la suppression du mot-clé utilisateur .

[Temps libre] Utilisé pour spécifier un délai de mot-clé utilisateur .

6.2 Toutes les options de ligne de commande

Cette annexe répertorie toutes les options de ligne de commande disponibles lors de
l' exécution de scénarios de test et lors du post-traitement des sorties . Les variables
d'environnement affectant l'exécution et le post-traitement sont également
répertoriées.

 6.2.1 Options de ligne de commande pour l'exécution du test

 6.2.2 Options de ligne de commande pour les sorties de post-traitement
 6.2.3 Variables d'environnement pour l'exécution et le post-traitement

6.2.1 Options de ligne de commande pour l'exécution

du test
-F, --extension <value>

Analyser uniquement ces fichiers lors de l'exécution d'un répertoire.

-N, --name <name>

Définit le nom de la suite de tests de niveau supérieur.

-D, --doc <document>

Définit la documentation de la suite de tests de niveau supérieur.

-M, --metadata <name:value>

Définit les métadonnées libres pour la suite de tests de niveau supérieur.

-G, --settag <tag>

 Définit la ou les balises sur tous les cas de test exécutés.

-t, --test <name>

Sélectionne les cas de test par nom .

-s, --suite <name>

Sélectionne les suites de tests par leur nom.

-R, --rerunfailed <file>

Sélectionne les tests ayant échoué à partir d'un fichier de

sortie précédent à ré-exécuter.

-S, --rerunfailedsuites <file>

Sélectionne les suites de tests ayant échoué à partir d'un fichier de

sortie antérieur à ré-exécuter.

-i, --include <tag>

Sélectionne les cas de test par tag.

-e, --exclude <tag>

Sélectionne les cas de test par tag.

-c, --critical <tag>

Les tests qui ont la balise donnée sont considérés comme critiques .

-n, --noncritical <tag>

Les tests qui ont la balise donnée ne sont pas critiques .

-v, --variable <name:value>

Définit les variables individuelles .

-V, --variablefile <path:args>

Définit les variables à l'aide de fichiers de variables .

-d, --outputdir <dir>

Définit où créer des fichiers de sortie .

-o, --output <file>

 Définit le chemin d'accès au fichier de sortie généré .

-l, --log <file>

Définit le chemin d'accès au fichier journal généré .

-r, --report <file>

Définit le chemin d'accès au fichier de rapport généré .

-x, --xunit <file>

Définit le chemin d'accès au fichier de résultats compatible

xUnit généré .

--xunitskipnoncritical

Marquer les tests non critiques sur le fichier de résultat compatible

xUnit comme étant ignorés.

-b, --debugfile <file>

Un fichier de débogage écrit lors de l'exécution.

-T, --timestampoutputs

Ajoute un horodatage à tous les fichiers de sortie.

--splitlog Fractionner le fichier journal en morceaux plus petits qui s'ouvrent dans
le navigateur de manière transparente.

--logtitle <title>

Définit un titre pour le journal de test généré.

--reporttitle <title>

Définit un titre pour le rapport de test généré.

--reportbackground <colors>

Définit les couleurs d'arrière-plan du rapport généré.

-L, --loglevel <level>

Définit le niveau de seuil pour la journalisation. Le niveau de

journalisation visible par défaut peut éventuellement être séparé par
deux points (:).
--suitestatlevel <level>

Définit le nombre de niveaux à afficher dans le tableau Statistics by

Suite dans les sorties.

--tagstatinclude <tag>

Inclut uniquement ces balises dans la table Statistics by Tag .

--tagstatexclude <tag>

Exclut ces balises du tableau Statistiques par balise .

--tagstatcombine <tags:title>

Crée des statistiques combinées basées sur des balises .

--tagdoc <pattern:doc>

Ajoute de la documentation aux balises spécifiées .

--tagstatlink <pattern:link:title>

Ajoute des liens externes à la table Statistics by Tag .

--removekeywords <all|passed|name:pattern|tag:pattern|for|wuks>

Supprime les données de mot clé du fichier journal généré.

--flattenkeywords <for|foritem|name:pattern|tag:pattern>

Aplatit les mots-clés dans le fichier journal généré.

--listener <name:args>

Définit un écouteur pour surveiller l'exécution du test.

--warnonskippedfiles

Affiche un avertissement lorsqu'un fichier non valide est ignoré .

--nostatusrc Définit le code retour sur zéro indépendamment des échecs dans les cas
de test. Les codes d'erreur sont renvoyés normalement.

--runemptysuite

Exécute des tests également si les suites de tests sélectionnées sont

vides .
--dryrun En mode de fonctionnement à sec , les tests sont exécutés sans exécuter
de mots-clés provenant des bibliothèques de test. Utile pour valider la
syntaxe des données de test.

-X, --exitonfailure

Arrête l'exécution du test si un test critique échoue.

--exitonerror Arrête l'exécution du test en cas d'erreur lors de l'analyse des données
de test, de l'importation de bibliothèques, etc.

--skipteardownonexit

Saute les démontages lorsque l' exécution du test est arrêtée

prématurément.

--prerunmodifier <name:args>

Activer la modification par programme des données de test .

--prerebotmodifier <name:args>

Activer la modification programmatique des résultats .

--randomize <all|suites|tests|none>

Aléatoire l' ordre d'exécution du test.

--console <verbose|dotted|quiet|none>

Type de sortie de la console .

--dotted Raccourci pour --console dotted.

--quiet Raccourci pour --console quiet.

-W, --consolewidth <width>

Définit la largeur de la sortie de la console.

-C, --consolecolors <auto|on|ansi|off>

Spécifie les couleurs utilisées sur la console.

-K, --consolemarkers <auto|on|off>

Afficher les marqueurs sur la console lorsque les mots-clés de niveau

supérieur se trouvent dans un scénario de test.
-P, --pythonpath <path>

Emplacements supplémentaires à ajouter au chemin de

recherche du module .

-E, --escape <what:with>

Échappe aux caractères problématiques dans la console.

-A, --argumentfile <path>

Un fichier texte pour lire plus d'arguments à partir de.

-h, --help Imprime les instructions d'utilisation .

--version Imprime les informations de version .

6.2.2 Options de ligne de commande pour les sorties de

post-traitement
-R, --merge Modifie le résultat en combinant le comportement à la fusion .

-N, --name <name>

Définit le nom de la suite de tests de niveau supérieur.

-D, --doc <document>

Définit la documentation de la suite de tests de niveau supérieur.

-M, --metadata <name:value>

Définit les métadonnées gratuites pour la suite de tests de niveau

supérieur.

-G, --settag <tag>

Définit la ou les balises sur tous les cas de test traités.

-t, --test <name>

Sélectionne les cas de test par nom .

-s, --suite <name>

Sélectionne les suites de tests par leur nom.

-i, --include <tag>

Sélectionne les cas de test par tag.

-e, --exclude <tag>

Sélectionne les cas de test par tag.

-c, --critical <tag>

Les tests qui ont la balise donnée sont considérés comme critiques .

-n, --noncritical <tag>

Les tests qui ont la balise donnée ne sont pas critiques .

-d, --outputdir <dir>

Définit où créer des fichiers de sortie .

-o, --output <file>

Définit le chemin d'accès au fichier de sortie généré .

-l, --log <file>

Définit le chemin d'accès au fichier journal généré .

-r, --report <file>

Définit le chemin d'accès au fichier de rapport généré .

-x, --xunit <file>

Définit le chemin d'accès au fichier de résultats compatible

xUnit généré .

--xunitskipnoncritical

Marquer les tests non critiques sur le fichier de résultat compatible

xUnit comme étant ignorés.

-T, --timestampoutputs

Ajoute un horodatage à tous les fichiers de sortie.

--splitlog Fractionner le fichier journal en morceaux plus petits qui s'ouvrent dans
le navigateur de manière transparente.
--logtitle <title>

Définit un titre pour le journal de test généré.

--reporttitle <title>

Définit un titre pour le rapport de test généré.

--reportbackground <colors>

Définit les couleurs d'arrière-plan du rapport généré.

-L, --loglevel <level>

Définit le niveau de seuil pour sélectionner les messages de

journal. Le niveau de journalisation visible par défaut peut
éventuellement être séparé par deux points (:).

--suitestatlevel <level>

Définit le nombre de niveaux à afficher dans le tableau Statistics by

Suite dans les sorties.

--tagstatinclude <tag>

Inclut uniquement ces balises dans la table Statistics by Tag .

--tagstatexclude <tag>

Exclut ces balises du tableau Statistiques par balise .

--tagstatcombine <tags:title>

Crée des statistiques combinées basées sur des balises .

--tagdoc <pattern:doc>

Ajoute de la documentation aux balises spécifiées .

--tagstatlink <pattern:link:title>

Ajoute des liens externes à la table Statistics by Tag .

--removekeywords <all|passed|name:pattern|tag:pattern|for|wuks>

Supprime les données de mots-clés des sorties générées.

--flattenkeywords <for|foritem|name:pattern|tag:pattern>
 Aplatit les mots-clés dans les sorties générées.

--starttime <timestamp>

Définit l' heure de début de l'exécution du test lors de la création de

rapports.

--endtime <timestamp>

Définit l' heure de fin de l'exécution du test lors de la création de

rapports.

--nostatusrc Définit le code retour sur zéro indépendamment des échecs dans les cas
de test. Les codes d'erreur sont renvoyés normalement.

--processemptysuite

Traite les fichiers de sortie même si les fichiers contiennent des suites de
tests vides .

--prerebotmodifier <name:args>

Activer la modification programmatique des résultats .

-C, --consolecolors <auto|on|ansi|off>

Spécifie les couleurs utilisées sur la console.

-P, --pythonpath <path>

Emplacements supplémentaires à ajouter au chemin de

recherche du module .

-E, --escape <what:with>

Échappe aux caractères problématiques dans la console.

-A, --argumentfile <path>

Un fichier texte pour lire plus d'arguments à partir de.

-h, --help Imprime les instructions d'utilisation .

--version Imprime les informations de version .

6.2.3 Variables d'environnement pour l'exécution et le

post-traitement
ROBOT_OPTIONS et REBOT_OPTIONS
Liste des options par défaut séparées par des espaces à placer devant toutes les
options explicites de la ligne de commande.
ROBOT_SYSLOG_FILE
Chemin d'accès à un fichier syslog où Robot Framework écrit des
informations internes sur l'analyse des fichiers de scénario de test et sur
l'exécution des tests.
ROBOT_SYSLOG_LEVEL
Niveau de journalisation à utiliser lors de l'écriture dans le fichier syslog .
ROBOT_INTERNAL_TRACES
Lorsqu'elles sont définies sur une valeur non vide, les méthodes internes de
Robot Framework sont incluses dans les retraits d'erreur .

6.3 Modèles de données de test

Ces modèles peuvent être utilisés lors de la création de données de test pour Robot
Framework. Il existe des modèles pour les fichiers de scénario de test et de ressource ,
et des modèles de ressource peuvent également être utilisés pour créer des fichiers
d'initialisation de suite de tests .

Les modèles sont disponibles au format HTML et au format TSV et peuvent être
personnalisés librement. Il n'y a pas de modèles pour le format texte brut car il
nécessite si peu de matrices que les modèles ne seraient pas très utiles.

testcase_template.html
Modèle de fichier de cas de test au format HTML.
testcase_template.tsv
Modèle de fichier de cas de test au format TSV.
resource_template.html
Modèle de fichier de ressources au format HTML.
resource_template.tsv
Modèle de fichier de ressources au format TSV.
attd_template.html
Modèle de création de scénarios de test dans le style de développement
piloté par les tests d'acceptation (ATDD). Ces tests sont créés à partir de
mots-clés de haut niveau ne nécessitant aucun argument, et le modèle a été
simplifié en conséquence.

Les modèles sont disponibles via ce guide de l'utilisateur, ils sont inclus dans la
distribution source et peuvent également être trouvés dans les pages du projet .

6.4 Formatage de la documentation

Il est possible d'utiliser un formatage simple HTML avec suite de tests , cas de
test et mot - clé utilisateur la documentation et les métadonnées de suite test gratuit dans
les données de test, ainsi que lors de la documentation des bibliothèques de test . Le
formatage est similaire au style utilisé dans la plupart des wikis, et il est conçu pour
être compréhensible à la fois en texte brut et après la transformation HTML.

 6.4.1 Représenter les nouvelles lignes

o Nouvelles lignes dans les données de test
o Documentation dans les bibliothèques de tests
 6.4.2 Paragraphes
 6.4.3 Styles en ligne
 6.4.4 URL
 6.4.5 Liens et images personnalisés
o Lien avec le contenu du texte
o Lien avec le contenu de l'image
o Image avec texte du titre
 6.4.6 Titres de section
 6.4.7 Tables
 6.4.8 Listes
 6.4.9 Texte préformaté
 6.4.10 Règle horizontale

6.4.1 Représenter les nouvelles lignes

Nouvelles lignes dans les données de test
Lorsque vous documentez des suites de tests, des cas de test et des mots-clés ou
que vous ajoutez des métadonnées à des suites de tests, vous pouvez ajouter des
nouvelles lignes manuellement à l'aide de la séquence de caractères de nouvelle
ligne ( \n).

*** Paramètres ***

Documentation Première ligne. \ N \ nDeuxième paragraphe, cette fois \ n
avec plusieurs lignes.
Exemple de métadonnées Valeur \ nin deux lignes

L'ajout de nouvelles lignes manuellement à une longue documentation demande un

certain effort et des caractères supplémentaires rendent la documentation plus
difficile à lire. À partir de Robot Framework 2.7, cela n'est pas nécessaire car les
nouvelles lignes sont automatiquement insérées entre la documentation continue et les
lignes de métadonnées . En pratique, cela signifie que l'exemple ci-dessus peut être
écrit de la manière suivante.
*** Paramètres ***
Documentation
... première ligne.
...
... Deuxième paragraphe, cette fois
... avec plusieurs lignes.
Métadonnées
... exemple
... valeur
... en deux lignes

Aucune nouvelle ligne automatique n'est ajoutée si une ligne se termine déjà par
une nouvelle ligne littérale ou si elle se termine par une barre oblique inverse . Si la
documentation ou les métadonnées sont définies dans plusieurs colonnes, les
cellules d'une même ligne sont concaténées avec des espaces. Ce type de
fractionnement peut être une bonne idée, en particulier lorsque vous utilisez
le format HTML et que les colonnes sont étroites. Différentes manières de diviser la
documentation sont illustrées dans les exemples ci-dessous, où tous les cas de test
finissent par avoir la même documentation à deux lignes.
*** Cas de test ***
Exemple 1
[ Documentation ] Première ligne \ n Deuxième ligne en plusieurs
parties
Pas d'opération

Exemple 2
[ Documentation ] Première ligne
... Deuxième ligne en plusieurs parties
Pas d'opération

Exemple 3
[ Documentation ] Première ligne \ n
... Deuxième ligne dans \
... plusieurs parties
Pas d'opération

Documentation dans les bibliothèques de tests

Avec les documentations de bibliothèque, les nouvelles lignes normales suffisent
et, par exemple, la documentation de mot-clé suivante crée le même résultat final
que la documentation de la suite de tests de la section précédente.
def example_keyword ():
"" "Première ligne.

Deuxième paragraphe, cette fois

avec plusieurs lignes.
"" "
passe

6.4.2 Paragraphes
À partir de Robot Framework 2.7.2, tout le texte normal de la documentation
HTML formatée est représenté par des paragraphes. En pratique, les lignes séparées
par une nouvelle ligne seront combinées dans un paragraphe, que la nouvelle ligne
soit ajoutée manuellement ou automatiquement. Plusieurs paragraphes peuvent être
séparés par une ligne vide (c.-à-d. Deux nouvelles lignes), ainsi que des tableaux,
des listes et d'autres blocs spécialement mis en forme, discutés dans les sections
suivantes et se terminant par un paragraphe.

Par exemple, la suite de tests ou la documentation du fichier de ressources suivante:

*** Paramètres ***
Documentation
... Le premier paragraphe n'a qu'une seule ligne.
...
... Deuxième paragraphe, cette fois créé
... avec plusieurs lignes.

sera formaté en HTML comme:

Le premier paragraphe n'a qu'une seule ligne.

Deuxième paragraphe, cette fois créé avec plusieurs lignes.

Remarque

Avant 2.7.2, la manipulation des paragraphes était incohérente. Dans la documentation

générée avec Libdoc, les lignes étaient combinées à des paragraphes, mais dans les
documentations affichées dans le journal et dans le rapport, elles ne l'étaient pas.

6.4.3 Styles en ligne

La syntaxe de la documentation prend en charge les styles en
ligne gras , italique et code. Le texte en gras peut être créé en ayant un astérisque
avant et après le ou les mots sélectionnés, par exemple *this is bold*. Le style
italique fonctionne de la même manière, mais le caractère spécial à utiliser est un
trait de soulignement, par exemple _italic_. Il est également possible d'avoir
italique gras avec la syntaxe _*bold italic*_.

Le style de code est créé en utilisant des raccourcis doubles tels que ``
code`` . Le résultat est un texte monospace avec un fond gris clair. La prise en
charge du style de code est nouvelle dans Robot Framework 2.8.6.

Les astérisques, les traits de soulignement ou les doubles repères simples, ou au

milieu d'un mot, ne commencent pas à être formatés, mais les caractères de
ponctuation avant ou après ceux-ci sont autorisés. Lorsque plusieurs lignes forment
un paragraphe , tous les styles en ligne peuvent s'étendre sur plusieurs lignes.

Exemples de style en ligne

Non formaté Formaté

*audacieux* audacieux

_italique_ italique
 _*gras italique*_ gras italique

`` code`` code

* bold *, puis _italic_ et enfin `` some code`` en gras , puis en italique et enfinsome code

Ceci est * en gras \ n Ceci est en gras

sur plusieurs sur plusieurs
lignes \ n . lignes .

6.4.4 URL
Toutes les chaînes qui ressemblent à des URL sont automatiquement converties en
liens cliquables. De plus, les URL se terminant par
l'extension .jpg , .jpeg , .png , .gif ou .bmp (insensible à la casse) créent
automatiquement des images. Par exemple, les URL
comme http://example.comsont transformées en
liens http:///host/image.jpget file:///path/chart.png en images.

La conversion automatique des URL en liens est appliquée à toutes les données des
journaux et des rapports, mais la création d'images est effectuée uniquement pour la
suite de tests, la documentation de cas de test et de mots clés, ainsi que pour les
métadonnées de suites de tests.

6.4.5 Liens et images personnalisés

À partir de Robot Framework 2.7, il est possible de créer des liens personnalisés et
d’intégrer des images à l’aide d’une syntaxe spéciale [link|content]. Cela crée un
lien ou une image en fonction de linket des contentimages. Elles sont considérées
comme des images si elles ont les mêmes extensions d’image spécifiques
aux URL . Les crochets environnants et le caractère de conduite entre les pièces
sont obligatoires dans tous les cas.

Lien avec le contenu du texte

Si ni une image, linkni contentune image, le résultat final est un lien normal où
se linktrouve la cible du lien et content le texte visible:
[fichier.html | ce fichier] -> <a href="file.html"> ce fichier </a>
[http: // hôte | cet hôte] -> <a href="http://host"> cet hôte </a>

Lien avec le contenu de l'image

Si contentest une image, vous obtenez un lien où le contenu du lien est une
image. La cible de lien est créée par linket peut être du texte ou de l'image:
 [robot.html | robot.png] -> <a href="robot.html"> <img src =
"robot.png"> </a>
[image.jpg | thumb.jpg] -> <a href="image.jpg"> <img src =
"thumb.jpg"> </a>

Image avec texte du titre

Si linkest une image mais qu'elle contentne l'est pas, la syntaxe crée une image
où contentest le texte du titre affiché lorsque la souris survole l'image:
[robot.jpeg | Robot rochers!] -> <img src = "robot.jpeg" title =
"Robot rochers!">

6.4.6 Titres de section

Si la documentation est plus longue, il est souvent conseillé de la diviser en
sections. À partir de Robot Framework 2.7.5, il est possible de séparer les sections
avec des titres en utilisant la syntaxe = My Title =, où le nombre de signes égaux
indique le niveau du titre:
= Première section =

== Sous-section ==

Du texte.

== Deuxième sous-section ==

Plus de texte

= Deuxième section =

Vous avez probablement eu l'idée.

Notez que seuls trois niveaux de titre sont pris en charge et que les espaces entre les
signes égaux et le texte du titre sont obligatoires.

6.4.7 Tables
Les tableaux sont créés à l'aide de caractères de conduite avec des espaces autour
d'eux en tant que séparateurs de colonnes et de nouvelles lignes en tant que
séparateurs de lignes. Les cellules d'en-tête peuvent être créées en entourant le
contenu de la cellule de signes égaux et d'espaces optionnels tels que = Header
=ou =Header=. Les cellules des tableaux peuvent également contenir des liens et un
format tels que gras et italique:
| = A = | = B = | = C = |
| _1_ | Bonjour monde! |
| _2_ Salut
La table créée a toujours une bordure fine et le texte normal est aligné à gauche. Le
texte dans les cellules d'en-tête est en gras et centré. Les cellules vides sont
automatiquement ajoutées pour rendre les lignes aussi longues. Par exemple,
l'exemple ci-dessus serait formaté comme ceci en HTML:

UNE B C
1 Bonjour monde
2 salut

Remarque

La prise en charge des en-têtes de tableau est une nouvelle fonctionnalité de Robot
Framework 2.8.2.

6.4.8 Listes
Les listes sont créées en commençant une ligne avec un trait d'union et un espace ('-
'). Les éléments de liste peuvent être divisés en plusieurs lignes en mettant en retrait
les lignes continues avec un ou plusieurs espaces. Une ligne qui ne commence pas
par '-' et n'est pas en retrait termine la liste:
Exemple:
- un élément de liste
- deuxième élément de la liste
est continué

Ceci est en dehors de la liste.

La documentation ci-dessus est formatée comme ceci en HTML:

Exemple:
 un élément de liste
 deuxième élément de la liste est continué

Ceci est en dehors de la liste.

Remarque

La prise en charge des listes de formatage a été ajoutée au 2.7.2. Avant cela, la même syntaxe
empêchait Libdoc de combiner des lignes en paragraphes, le résultat final était donc
similaire. La prise en charge du fractionnement d'éléments de liste en plusieurs lignes a été
ajoutée au 2.7.4.

6.4.9 Texte préformaté

À partir de Robot Framework 2.7, il est possible d'incorporer des blocs de texte
préformaté dans la documentation. Le bloc préformaté est créé en commençant par
des lignes avec '| «Un espace est obligatoire après le caractère de conduite, sauf sur
les lignes vides. Le départ '| La séquence sera supprimée du code HTML résultant,
mais tous les autres espaces seront conservés.

Dans la documentation suivante, les deux lignes médianes forment un bloc

préformaté lorsqu'elles sont converties en HTML:
Doc avant bloquer:
| bloc intérieur
| des espaces supplémentaires
Après le bloc.

La documentation ci-dessus est formatée comme suit:

Doc avant bloquer:

bloc intérieur
des espaces supplémentaires
Après le bloc.

Lorsque vous documentez des suites, des tests ou des mots-clés dans les données de
test de Robot Framework, le fait d'avoir plusieurs espaces nécessite de s'échapper
avec une barre oblique inverse pour éviter d'ignorer les espaces . L'exemple ci-dessus
serait ainsi écrit comme ceci:
Doc avant bloquer:
| bloc intérieur
| \ \ \ certains \ \ espaces supplémentaires blancs
Après le bloc.

6.4.10 Règle horizontale

Les règles horizontales (la <hr>balise) permettent de séparer des sections plus
grandes les unes des autres, et elles peuvent être créées en ayant trois tirets ou plus
sur une même ligne:
Du texte ici.

---

Plus de texte ...

La documentation ci-dessus est formatée comme suit:

Du texte ici.

Plus de texte ...

6.5 Format de l'heure
Robot Framework a son propre format temporel à la fois flexible et facile à
comprendre. Il est utilisé par plusieurs mots-clés (par exemple, mots-clés intégrés
en veille et en attente jusqu'à la réussite du mot-clé ), la bibliothèque DateTime et
les délais d'attente .

6.5.1 Heure comme numéro

Le temps peut toujours être donné sous la forme d'un nombre clair, auquel cas il est
interprété comme étant des secondes. Les nombres entiers et les nombres à virgule
flottante fonctionnent, et il est possible d'utiliser des nombres réels ou des chaînes
contenant des valeurs numériques.

6.5.2 Heure comme chaîne de temps

Représenter l'heure sous forme de chaîne de temps signifie utiliser un format tel
que 2 minutes 42 seconds, qui est normalement plus facile à comprendre que la
simple valeur en secondes. Par exemple, il n'est pas si facile de comprendre
combien de temps il 4200faut en secondes, mais cela 1 hour 10 minutesest clair
immédiatement.

L'idée de base de ce format est d'avoir d'abord un numéro et ensuite un texte

indiquant l'heure à laquelle ce nombre représente. Les nombres peuvent être des
nombres entiers ou des nombres à virgule flottante, le format entier est insensible à
la casse et à l'espace, et il est possible d'ajouter un -préfixe pour spécifier des temps
négatifs. Les spécificateurs de temps disponibles sont:

 jours, jour, d
 heures, heure, h
 minutes, minutes, minutes, min, m
 secondes, secondes, secondes, sec, s
 millisecondes, millisecondes, millis, ms

Exemples:
1 min 30 s
1,5 minutes
90 s
1 jour 2 heures 3 minutes 4 secondes 5 millisecondes
1d 2h 3m 4s 5ms
- 10 secondes

6.5.3 Heure comme chaîne "timer"

À partir de la version 2.8.5 de Robot Framework, le temps peut également être
donné au format minuterie hh:mm:ss.mil. Dans ce format, les parties heure et
milliseconde sont facultatives, les zéros de début et de fin peuvent être omis
lorsqu'ils ne sont pas significatifs, et les temps négatifs peuvent être représentés en
ajoutant le - préfixe. Par exemple, les valeurs de temporisation et de chaîne de
temps suivantes sont identiques:

Exemples de minuterie et de chaîne de temps

Minuteur Chaîne de temps

00:00:01 1 seconde

01:02:03 1 heure 2 minutes 3 secondes

1:00:00 1 heure

100: 00: 00 100 heures

00:02 2 secondes

42:00 42 minutes

00: 01: 02.003 1 minute 2 secondes 3 millisecondes

00: 01.5 1,5 secondes

-01: 02.345 - 1 minute 2 secondes 345 millisecondes

6.6 Arguments booléens

De nombreux mots clés dans les bibliothèques standard de Robot
Framework acceptent les arguments traités comme des valeurs booléennes true ou
false. Si un tel argument est donné sous forme de chaîne, il est considéré comme
faux s'il est vide ou insensible à la casse falseou no. Les autres chaînes sont
considérées comme vraies, quelle que soit leur valeur, et les autres types
d'arguments sont testés en utilisant les mêmes règles qu'en Python .

Mot - clé peut également accepter d' autres chaînes spéciales que falseet noqui
doivent être considérées comme fausses. Par exemple, le mot-clé BuiltInShould Be
True utilisé dans les exemples ci-dessous considère que la chaîne no valuesdonnée
à son values argument est fausse.
*** Mots clés ***
Vrais exemples
Devrait être égal $ { x } $ { y } Valeurs d' erreur
personnalisées = Vrai # Les chaînes sont généralement vraies. Devrait être
égal à $ { x } $ { y } Valeurs d' erreur personnalisées = oui #
Identique à ce qui précède. Devrait être égal à $ { x } $ { y }
Valeurs d' erreur personnalisées = $ { TRUE } # Python `True` est
vrai. Devrait être égal à $ { x } $ { y } Valeurs d' erreur
personnalisées = $ { 42 }

# Les nombres autres que 0 sont vrais.

Faux exemples
Devrait être égal $ { x } $ { y } Valeurs d' erreur
personnalisées = False # Chaîne `false` est fausse. Devrait être égal à
$ { x } $ { y } Valeurs d' erreur personnalisées = non # La chaîne
"non" est également fausse. Devrait être égal à $ { x } $ { y }
Valeurs d' erreur personnalisées = $ { EMPTY } # La chaîne vide est
fausse. Devrait être égal à $ { x } $ { y } Valeurs d' erreur
personnalisées = $ { FALSE }

# Python `False` est faux.

Devrait être égal à $ { x } $ { y } Valeurs d' erreur
personnalisées = aucune valeur # Chaîne de caractères spéciale dans ce
contexte.

Notez qu'avant Robot Framework 2.9, la gestion des arguments booléens était
incohérente. Certains mots-clés suivaient les règles ci-dessus, mais d'autres
considéraient simplement que toutes les chaînes non vides, y compris falseet no,
étaient vraies.

6.7 API interne

À partir de Robot Framework 2.7, la documentation de l'API est hébergée séparément
sur l'excellent service Read the Docs . Si vous ne savez pas comment utiliser
certaines API ou si vous les utilisez, veuillez envoyer une question à la liste de
diffusion .

Généré par reStructuredText . Mise en évidence de la syntaxe par Pygments .

Généré le: 2018-04-25 20:41 UTC.