The Robot Framework is a test framework to automate acceptance tests. Docker is a well-known and widely used container solution. In this article we will combine both tools showing the benefits this has in using the Robot Framework.
It is almost impossible to not hear about Docker nowadays. But up to now I was somehow never really hooked. This has changed with a new colleague joining our project and giving a really good – and especially practical – introduction to Docker. No wonder, considering one of his favorite projects is Testcontainers . A project that is definitely worth a blog post of its own. Anyway, more or less immediately, my mind started circling around the idea of a dockerized way to use the Robot Framework, and here we are.
Of course there are already ready-made Robot Framework Docker images on Docker Hub . Any suitbale image can in principle be used to get started right away. The idea of this blog post is to have a bit of a closer look at how things work together. This should allow for a more tailored approach when using the Robot Framework together with Docker.
Spoiler: It will turn out to be much easier than one might think.
Why utilize Docker for the Robot Framework?
Before diving deeper into the technical aspects of this article, let’s first ask: Why should we be using a dockerized approach in the first place?
There are three main advantages in utilizing Docker over a standalone Robot Framework installation:
- Installation only requires one tool (Docker) instead of multiple tools (Python, pip, Robot Framework, test libraries, potentially Java).
- Installation is harmonized over all team members and the CI environment in one central place.
- Updating versions of individual components can be easily tried out using a separate Docker image.
These three points really have a huge positive impact on the installation and usage of the Robot Framework. Even though installation is quite easy by now, it still requires certain tools (like Python, pip or Java) that might not be available right away on every machine. This might especially be true for non-developer machines.
Having a commonly harmonized Robot Framework installation will save time and avoid problems due to different versions or operating systems used within a team and on the CI environment. Thus ramp-up time for new team members will also be shorter.
Being able to update the testing framework without doing harm to any existing installation is of course also quite beneficial.
Depending on the use case it might be even possible to have the application under test installed to another Docker container. Then Docker Compose could be used to tie things together for a complete testing environment. This would eliminate the need for common test environments or running the application locally to execute tests. Might be good to keep that idea in mind even though it exceeds the scope of this article.
With these advantages in mind let’s start with the practical part or our endeavor.
Installing Docker
Obviously having a Docker installation is the prerequisite for everything that comes next. Luckily the installation is pretty straightforward. For Windows and Mac OS there are installers available (though you need to create an account on Docker Hub):
For Linux it depends on the distribution. Instructions for the different distributions can be found here .
The examples in this article are based on Docker running under Mac OS.
Minimal example
There are two ways to use Docker in your own projects. Simply use ready-made images or create your own images and then use those afterwards in your project. The following is a simple example of using an existing image. At the same time it is a good test for your Docker installation:
➜ docker run hello-world
You will get a nice “Hello World” and some confirmation that Docker is installed properly.
Now let’s create our very first Docker image containing a basic Robot Framework installation. For this we are writing a so-called docker file that is named Dockerfile in some empty directory. It should have the following content:
FROM python:3
RUN python3 -m pip install robotframework
Run the following command to create your first container image:
➜ docker build .
The output will be similar to:
Sending build context to Docker daemon 54.78kB
Step 1/2 : FROM python:3
---> ac069ebfe1e1
Step 2/2 : RUN python3 -m pip install robotframework
---> Using cache
---> bbf36a3d6fa1
Successfully built bbf36a3d6fa1
What’s important is the bbf36a3d6fa1 as this currently is the “name” of your Docker image. With this, you can now start the container as follows:
➜ docker run -ti bbf36a3d6fa1 bash
You get a root shell inside the container where you can now start the Robot Framework. Let’s simply check the version of the installed Robot Framework:
root@52491baf364f:/# robot --version
Robot Framework 3.1.1 (Python 3.7.2 on linux)
root@52491baf364f:/#
Now of course it is nicer working with some real name instead of a cryptic generated hash. No problem, just use the following commands (of course you should use some different name than “tjaspers” here):
➜ docker build -t tjaspers/robot-docker .
➜ docker run -ti tjaspers/robot-docker bash
This article is not intended to be a full-blown Docker tutorial. But let’s have a quick recap of some of the key spots of what we have just done.
Dockerfile: FROM python:3
This command in the Dockerfile defines the base image for our installation. Most Docker images are based on a common Linux distribution, such as Debian or Alpine (there is also a special kind of image, called SCRATCH, which is basically a completely empty image). Here we are getting a Linux installation together with Python 3. As the Robot Framework is a native Python application, this seems to be a good starting point.
Dockerfile: RUN python3 -m pip install robotframework
Installing the Robot Framework using the Python installer tool pip is the recommended way to do so. Here it is only prefixed by the Docker command RUN. This already gives an idea how easy it will be to extend the Robot Framework installation in the Dockerfile.
Building the Docker image: docker build -t tjaspers/robot-docker .
This is simply the command to build the Docker image out of the (descriptive) Dockerfile. Giving it a name makes it much easier to use it again later on.
Executing the Docker image: docker run -ti tjaspers/robot-docker bash
This commands starts the just build Docker image. In this case we are getting a bash shell as we have given this as a command to “docker run”. We will see in a few moments how these kinds of commands can help us improve the whole approach.
Extended example
There are only very few things missing to make this really cool. Of course we would like to execute tests from our local hard disk. For this, we can mount a local directory when starting the container using the -v option:
docker run -ti -v /Users/thomasjaspers/Documents/projects/codecentric/robot-framework/robot-keyword-tutorial:/usr/src/project tjaspers/robot-docker bash
To test the approach, the following keyword example project is used . On my machine the project is located in the following directory: “/Users/thomasjaspers/Documents/projects/codecentric/robot-framework/robot-keyword-tutorial”. In the Docker image this directory will be mounted to “/usr/src/project”. Now we can execute the tests inside the container:
root> cd /usr/src/project/
root> robot sample-0-trivial/sample-0-trivial.txt
This will generate the following output:
[ WARN ] Automatic parsing other than '*.robot' files is deprecated. Convert '/usr/src/project/sample-0-trivial/sample-0-trivial.txt' to '*.robot' format or use '--extension' to explicitly configure which files to parse.
==============================================================================
Sample-0-Trivial
==============================================================================
Test Robot Framework Logging | PASS |
------------------------------------------------------------------------------
Sample-0-Trivial | PASS |
1 critical test, 1 passed, 0 failed
1 test total, 1 passed, 0 failed
==============================================================================
Output: /usr/src/project/output.xml
Log: /usr/src/project/log.html
Report: /usr/src/project/report.html
Ok, it seems like it is time to update the test project files. But aside from the warning everything has worked fine. And another really good thing is that the reports written by the Robot Framework are directly available from the local disk.
The latest Dockerfile used in this example can be found here. .
Now only one final step is missing. Of course we do not want to execute commands every time inside the container. Instead we want the tests to be executed right away when starting the container. This can be achieved by adding the following command to the Dockerfile:
CMD ["robot", "-d", "/usr/src/project/", "/usr/src/project/sample-0-trivial/sample-0-trivial.txt"]
Now we can start the tests by simply omitting the “bash”-command at the end of our “docker run” call. Thus the command defined inside the Dockerfile will be executed.
➜ docker run -ti -v /Users/thomasjaspers/Documents/projects/codecentric/robot-framework/robot-keyword-tutorial:/usr/src/project tjaspers/robot-docker
[ WARN ] Automatically parsing other than '*.robot' files is deprecated. Convert '/usr/src/project/sample-0-trivial/sample-0-trivial.txt' to '*.robot' format or use '--extension' to explicitly configure which files to parse.
==============================================================================
Sample-0-Trivial
==============================================================================
Test Robot Framework Logging | PASS |
------------------------------------------------------------------------------
Sample-0-Trivial | PASS |
1 critical test, 1 passed, 0 failed
1 test total, 1 passed, 0 failed
==============================================================================
Output: /output.xml
Log: /log.html
Report: /report.html
This starts the tests right away using the Robot Framework installed to the Docker container and the locally stored test suite. Team members can still use different local directories also depending on used operating systems. Typically the test suites will anyway be under version control, which fits this approach very well. Basically it is possible to have one container for one project. This way the call to execute the tests can be hardcoded and we have clearly separated versions for different projects.
Conclusion
The above shown example can of course be extended by adding the installation of additional test libraries to the Dockerfile. This can be seen from the full sample Dockerfile that can be found here .
Furthermore more options can be given in the command executing the Robot Framework tests.
Anyway, overall the effort for a dockerized Robot Framework approach is quite low. Of course this still needs to be evaluated for the specific use case. Overall, this solution is definitely worth a try and should be considered in your Robot Framework projects.
Was this post helpful?
More articles
fromThomas Jaspers
12.1.2018 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.