This project consists of a Docker image containing a Robot Framework installation.
This installation also contains Firefox, Chrome and the Selenium library for Robot Framework. The test cases and reports should be mounted as volumes.
The versioning of this image follows the one of Robot Framework:
The versions used are:
As stated by the official GitHub project, starting from version 3.0, Selenium2Library is renamed to SeleniumLibrary and this project exists mainly to help with transitioning. The Selenium2Library 3.0.0 is also the last release and for new releases, please look at the SeleniumLibrary project.
This container can be run using the following command:
docker run \
-v <local path to the reports' folder>:/opt/robotframework/reports:Z \
-v <local path to the test suites' folder>:/opt/robotframework/tests:Z \
ppodgorsek/robot-framework:<version>
Browsers can be easily switched. It is recommended to define ${BROWSER} %{BROWSER}
in your Robot variables and to use ${BROWSER}
in your test cases. This allows to set the browser in a single place if needed.
When running your tests, simply add -e BROWSER=chrome
or -e BROWSER=firefox
to the run command.
It is possible to define the settings of the virtual screen in which the browser is run by changing several environment variables:
SCREEN_COLOUR_DEPTH
(default: 24)SCREEN_HEIGHT
(default: 1080)SCREEN_WIDTH
(default: 1920)It is possible to use different directories to read tests from and to generate reports to. This is useful when using a complex test file structure. To change the defaults, set the following environment variables:
ROBOT_REPORTS_DIR
(default: /opt/robotframework/reports)ROBOT_TESTS_DIR
(default: /opt/robotframework/tests)It is possible to parallelise the execution of your test suites. Simply define the ROBOT_THREADS
environment variable, for example:
docker run \
-e ROBOT_THREADS=4 \
ppodgorsek/robot-framework:latest
By default, there is no parallelisation.
When using parallelisation, it is possible to pass additional pabot options, such as --testlevelsplit
, --argumentfile
, --ordering
, etc. These can be passed by using the PABOT_OPTIONS
environment variable, for example:
docker run \
-e ROBOT_THREADS=4 \
-e PABOT_OPTIONS="--testlevelsplit" \
ppodgorsek/robot-framework:latest
RobotFramework supports many options such as --exclude
, --variable
, --loglevel
, etc. These can be passed by using the ROBOT_OPTIONS
environment variable, for example:
docker run \
-e ROBOT_OPTIONS="--loglevel DEBUG" \
ppodgorsek/robot-framework:latest
This project includes the IMAP library which allows Robot Framework to connect to email servers.
A suggestion to automate email testing is to run a Mailcatcher instance in Docker which allows IMAP connections. This will ensure emails are discarded once the tests have been run.
This project is meant to allow your tests to run anywhere. Sometimes that can be in a different timezone than your local one or of the location under test. To help solve such issues, this image includes the DateTimeTZ Library.
To set the timezone used inside the Docker image, you can set the TZ
environment variable:
docker run \
-e TZ=America/New_York \
ppodgorsek/robot-framework:latest
By default, containers are implicitly run using --user=1000:1000
, please remember to adjust that command-line setting accordingly, for example:
docker run \
--user=1001:1001 \
ppodgorsek/robot-framework:latest
Remember that that UID/GID should be allowed to access the mounted volumes in order to read the test suites and to write the output.
Additionally, it is possible to rely on user namespaces to further secure the execution. This is well described in the official container documentation:
This is a good security practice to make sure containers cannot perform unwanted changes on the host. In that sense, Podman is probably well ahead of Docker by not relying on a root daemon to run its containers.
It is possible to run the project from within a Jenkins pipeline by relying on the shell command line directly:
pipeline {
agent any
stages {
stage('Functional regression tests') {
steps {
sh "docker run --shm-size=1g -e BROWSER=firefox -v $WORKSPACE/robot-tests:/opt/robotframework/tests:Z -v $WORKSPACE/robot-reports:/opt/robotframework/reports:Z ppodgorsek/robot-framework:latest"
}
}
}
}
The pipeline stage can also rely on a Docker agent, as shown in the example below:
pipeline {
agent none
stages {
stage('Functional regression tests') {
agent { docker {
image 'ppodgorsek/robot-framework:latest'
args '--shm-size=1g -u root' }
}
environment {
BROWSER = 'firefox'
ROBOT_TESTS_DIR = "$WORKSPACE/robot-tests"
ROBOT_REPORTS_DIR = "$WORKSPACE/robot-reports"
}
steps {
sh '''
/opt/robotframework/bin/run-tests-in-virtual-screen.sh
'''
}
}
}
}
When relying on Continuous Integration tools, it can be useful to define a test run ID such as the build number or branch name to avoid overwriting consecutive execution reports.
For that purpose, the ROBOT_TEST_RUN_ID
variable was introduced:
${ROBOT_REPORTS_DIR}/
${ROBOT_REPORTS_DIR}/${ROBOT_TEST_RUN_ID}/
It can simply be passed during the execution, such as:
docker run \
-e ROBOT_TEST_RUN_ID="feature/branch-name" \
ppodgorsek/robot-framework:latest
By default, the test run ID is empty.
To upload the report of a test run to an S3 bucket, you need to define the following environment variables:
docker run \
-e AWS_ACCESS_KEY_ID=<your AWS key> \
-e AWS_SECRET_ACCESS_KEY=<your AWS secret> \
-e AWS_DEFAULT_REGION=<your AWS region e.g. eu-central-1> \
-e AWS_BUCKET_NAME=<name of your S3 bucket> \
ppodgorsek/robot-framework:latest
Not convinced yet? Simple tests have been prepared in the test/
folder, you can run them using the following commands:
# Using Chromium
docker run \
-v `pwd`/reports:/opt/robotframework/reports:Z \
-v `pwd`/test:/opt/robotframework/tests:Z \
-e BROWSER=chrome \
ppodgorsek/robot-framework:latest
# Using Firefox
docker run \
-v `pwd`/reports:/opt/robotframework/reports:Z \
-v `pwd`/test:/opt/robotframework/tests:Z \
-e BROWSER=firefox \
ppodgorsek/robot-framework:latest
For Windows users who use PowerShell, the commands are slightly different:
# Using Chromium
docker run \
-v ${PWD}/reports:/opt/robotframework/reports:Z \
-v ${PWD}/test:/opt/robotframework/tests:Z \
-e BROWSER=chrome \
ppodgorsek/robot-framework:latest
# Using Firefox
docker run \
-v ${PWD}/reports:/opt/robotframework/reports:Z \
-v ${PWD}/test:/opt/robotframework/tests:Z \
-e BROWSER=firefox \
ppodgorsek/robot-framework:latest
Screenshots of the results will be available in the reports/
folder.
Chrome drivers might crash due to the small size of /dev/shm
in the docker container:
UnknownError: session deleted because of page crash
This is a known bug of Chromium.
To avoid this error, please change the shm size when starting the container by adding the following parameter: --shm-size=1g
(or any other size more suited to your tests)
In case further investigation is required, the logs can be accessed by mounting their folder. Simply add the following parameter to your run
command:
-v `pwd`/logs:/var/log:Z
-v ${PWD}/logs:/var/log:Z
Chromium allows to set additional environment properties, which can be useful when debugging:
webdriver.chrome.verboseLogging=true
: enables the verbose logging modewebdriver.chrome.logfile=/path/to/chromedriver.log
: sets the path to Chromium's log fileWhen running tests, an unexpected error sometimes occurs:
[Error] Suite contains no tests.
There are two main causes to this:
As there can sometimes be issues as to where the tests are run from, make sure the correct folder is used by trying the following actions:
`pwd`
or ${PWD}
by the full path to the folder.It is also important to check if Robot Framework is allowed to access the resources it needs, i.e.:
As per their official project page, the Robot Framework DatabaseLibrary contains utilities meant for Robot Framework's usage. This can allow you to query your database after an action has been made to verify the results. This is compatible with any Database API Specification 2.0 module.
It is anyway mandatory to extend the container image to install the specific database module relevant to your tests, such as:
pip install pymssql
pip install pymysql
pip install py2oracle
pip install pg8000
Have you found an issue? Do you have an idea for an improvement? Feel free to contribute by submitting it on the GitHub project.
Test File包含了四部分:Setting(required), Variable(optional), Test Case(required), Keyword(optional) Setting、Test Case是必须的 Variable只有当需要变量的时候才有用 Keyword只有当standard libraries及external libraries没有,需要将多个keyword
一、列表 1.创建一个列表,关键字 create list, 来自Builtin库,返回一个列表,用@{list}接收 @{list} = Create List a b c 2.得到列表的长度, 关键字get length, 来自Builtin库 ${length} get length @{list} 3.在列表中添加内容, 关键字append to list,来自Collec
Docker On CentOS 不建议在CentOS6下面安装,运行效率会出现问题,请至少使用CentOS7 以上版本,本文中使用的是CentOS7.6 简单安装 yum install -y docker 或者使用更新的版本,依照如下操作 yum源安装 准备 更新yum yum install -y epel-release yum update -y yum install -y yum-
Robot Framework用于Web项目测试需要使用到的相关环境与工具 1、Python:https://www.python.org/Robot framework是基于Python的,需要有Python基础环境可以选用版本python-3.7.5-amd64.exe安装完后手动添加环境变量:鼠标右键我的电脑 -> 属性 -> 点击高级系统设置 -> 点击环境变量 -> 点击PATH ->
weixin-robot 是一个微信机器人,是本人在学习使用 Node.js 的过程中,为激发自身的学习热情而做的项目。 功能 已经实现的功能 文字信息的转发 图片的转发 尚未实现的功能 对微信消息中连接消息的转发 引入持久化存储,记录每次转发的消息 完善log日志(目前很多log语句被注释掉,log的格式也不一致)
wukong-robot 是一个简单、灵活、优雅的中文语音对话机器人/智能音箱项目,目的是让中国的 Maker 和 Haker 们也能快速打造个性化的智能音箱。 wukong-robot 还可能是第一个开源的支持脑机唤醒的智能音箱。 特性 模块化。功能插件、语音识别、语音合成、对话机器人都做到了高度模块化,第三方插件单独维护,方便继承和开发自己的插件。 中文支持。集成百度、科大讯飞、阿里、腾讯等多
叮当是一款可以工作在 Raspberry Pi 上的中文语音对话机器人/智能音箱项目。 叮当包括以下诸多特性: 模块化。功能插件、语音识别、语音合成、对话机器人都做到了高度模块化,第三方插件单独维护,方便继承和开发自己的插件。 微信接入。支持接入微信,并通过微信远程操控自己家中的设备。 中文支持。集成百度、科大讯飞、阿里、谷歌等多家中文语音识别和语音合成技术,且可以继续扩展。 对话机器人支持。支
deploy-robot 是 SegmentFault 出品的 Github 自动部署机器人,将你从繁冗的部署工作中解放出来,让你的部署流程更加自动化。 特点: 与 GitHub 深度整合,利用 GitHub API 读取相关部署指令,并及时反馈部署情况 与人工部署不同的是,自动部署不会疲劳,也不会喊累,你永远可以不停地折腾它 使用方法 执行以下命令安装 npm install -g deploy
Robot Emil 是一个用来学习编程的小游戏,通过编写一些固定的指令可以控制机器人的各种行为,包括行走、转弯和放置砖块。
Robot Framework是用于接受测试,接受测试驱动的开发(ATDD)和机器人流程自动化(RPA)的通用开源自动化框架。它具有简单的纯文本语法,并且可以使用使用Python或Java实现的库轻松扩展。 Robot Framework是独立于操作系统和应用程序的。该核心框架使用Python实现,同时支持Python 2和Python 3,并且还可以在Jython(JVM), IronPytho