A flexible and scalable container based Selenium Grid with video recording, live preview, basic auth & dashboard.
Start a Selenium Grid in seconds, a grid that scales up and down dynamically with this solution based on docker-selenium to run your tests in Firefox and Chrome. If you need a different browser, Zalenium can redirect your tests to a cloud testing provider (Sauce Labs, BrowserStack, TestingBot, CrossBrowserTesting, LambdaTest).
Zalenium works out of the box in Docker and Kubernetes.
We improve Zalenium regularly. Please try it, and help us to improve it by reporting bugs or suggesting features through the issue tracker. Zalenium is 100% open source and it is both yours and ours, that is why we invite you to contribute to it.
This project is powered by GitHub s, support us by starring it!
Why
Thanks for open sourcing this. Our test suite run time has dropped from more than an hour to six minutes. — @TKueck
We know how complicated it is to:
- Have a stable grid to run UI tests with Selenium
- Maintain it over time (keep up with new browser, Selenium and drivers versions)
- Provide capabilities to cover all browsers and platforms
That is why we took this approach where docker-selenium nodes are created on demand. Your UI tests run faster in Firefox and Chrome because they are running in your own local network, on a node created from scratch and disposed after the test completes.
If you need a capability that cannot be fulfilled by docker-selenium, the test gets redirected to a cloud testing provider (Sauce Labs, BrowserStack, TestingBot, CrossBrowserTesting, LambdaTest).
Zalenium’s main goal is: to allow anyone to have a disposable and flexible Selenium Grid infrastructure.
Part of the idea comes from this Sauce Labs post.
What does Zalenium mean?
As you can imagine, it is the result of mixing Zalando and Selenium. As mentioned before, this project’s aim is to provide a simple way to create a grid and contribute to the Selenium community. Nevertheless, this is not an official Selenium project. We kindly ask you to create issues in this repository. If you have questions about how to get started, please join the #zalenium channel on Slack.
Try It
Get a grid up and running in a few seconds!
Prerequisites
- Docker version >= 1.11.1 (probably works with earlier versions, not tested yet).
- Make sure that
docker info
works without errors.
Run it
This is the quick start for the docker version, for kubernetes see here.
Or without pulling elgalu/selenium
explicitly:
Try also our one line installer and starter for OSX/Linux (it will check for the latest images and ask for missing dependencies).
Why --privileged
? We suggest you run Zalenium as
--privileged
to speed up the node registration process by increasing the entropy
level with Haveged. Using it is optional since it is just meant
to improve its performance. For more information, check this
tutorial.
Features
Additional Features
- Test status and steps directly in the video
- Basic auth grid protection when deploying Zalenium in the cloud (AWS, GCP, …)
- Mount volumes across containers when you need to specific files in your tests
Before starting
Make sure that docker info
works without errors, and also check that you have pulled these images:
Starting Zalenium
Linux
OSX
Zalenium for OSX is currently compatible with Docker 17.03.1-ce
, 17.06.2-ce
, and 17.09.0-ce
.
Nevertheless, starting with 1.13, newer CLIs can talk to older daemons. If you bump into any API compatibility issues,
you can explicitly tell Zalenium which version you are using via -e DOCKER=17.06.2-ce
.
Windows
Special Cases and Customisations
(Click on the item to display its contents)
Enabling Sauce Labs (you'll need an account with them)
Enabling BrowserStack (you'll need an account with them)
Enabling TestingBot (you'll need an account with them)
Enabling CrossBrowserTesting (you'll need an account with them)
Enabling LambdaTest (you'll need an account with them)
Customising screen width and height, and time zone
Mounting volumes/folders across containers
/tmp/node/
, and it will be mapped across all the docker-selenium
containers from the root folder after stripping the /tmp/node/
prefix.
For example, mounting:
-v /your/local/folder:/tmp/node/home/seluser/folder
will map to /home/seluser/folder
on the node.
This can be used to provide further customization to your nodes, such as adding client certificates for your browser, or mimicking prior multi-purpose folder, both shown below. Please take caution in mounting system folders such as
/etc
, as this
behavior has not been tested with such configuration.
NOTE: There are certain protected points which cannot be mounted via
/tmp/node/
. See
PROTECTED_NODE_MOUNT_POINTS at DockerContainerClient.
Run more than one test per node
--maxTestSessions
. If you setup this flag to a value higher than 1,
Zalenium will run up to that given value of tests per node/container. Tuning this value for your test suites
should help to reduce the overall execution time since less containers/nodes are started and stopped on demand.
Here is an example:
This means that up to 4 tests will run in each node/container started by Zalenium. You could combine this parameter
with --desiredContainers
to get an optimal setup for your tests.
For example, if you have 20 tests that should run with 5 threads, you could start Zalenium with
--desiredContainers 5
and --maxTestSessions 4
. Therefore, 4 tests would be executed in each one
of the 5 nodes/containers and the whole test execution should finish earlier.
Video Feature
/home/seluser/videos
,
it will copy all the generated videos from the executed tests into your host mapped folder.
For example, starting Zalenium like this: will copy the generated videos to your local
/tmp/videos
folder. This
means all videos generated from tests executed in docker-selenium containers, including the ones executed in
an integrated cloud testing platform (Sauce Labs, BrowserStack, TestingBot).
The file name will be usually like this:
-
Zalenium:
containerName_testName_browser_platform_timestamp.mp4
- E.g.
zalenium_myTestName_chrome_linux_20170216071201.mp4
- E.g.
-
Cloud Testing Platform:
cloudPlatform_testName_browser_platform_timestamp.mp4
- E.g. Sauce Labs
saucelabs_myCloudTestName_safari_mac_20170216071201.mp4
- E.g. BrowserStack
browserstack_myCloudTestName_firefox_windows_20170216071201.mp4
- E.g. Sauce Labs
If the test name is not set via a capability, the Selenium session ID will be used.
Accessing the host
Linux
OSX and Windows
In OSX and Windows environments the
--net=host
flag is not supported yet. For that,
Docker has a workaround, which is to use gateway.docker.internal
to access the host
machine. So if the SUT is running on port 8080, you can do
http://gateway.docker.internal:8080
to access it.
More details can be seen at OSX docs
and Windows docs
Adding hosts to the containers
/etc/hosts
file in order
to mock dependencies, reach parts of your test infrastructure, or just to simplify your test code. Zalenium
supports the --add-host
flag in docker
run ...
and the extra_hosts
option in docker-compose. Here is
an example:
Adding proxy configuration to the containers
http_proxy=http://myproxy.example.com:8080
. Zalenium allows you to
configure this values and they will be passed into the created containers. The variables are called:
zalenium_http_proxy
,
zalenium_https_proxy
,
and zalenium_no_proxy
. You can pass them as enviromental variables
when starting Zalenium, here is an example:
Enabling basic auth
--gridUser
and --gridPassword
. Here are the detailed
instructions:
Providing a file with user(s) and password(s)
To create a file with that information, please follow the steps for "Creating a Password File" described in the Nginx documentation. After that, map the created file to the container when you start Zalenium, e.g.:Using the --gridUser
and --gridPassword
parameters
Using Zalenium when the basic auth is enabled
You will need to provide the user and the password stated in the file or in the parameters at the moment of running your tests. Here is and example that shows you how to do it (the user will beyourUser
and the password yourPassword
).
Setting CPU and Memory limits
ZALENIUM_SELENIUM_CONTAINER_CPU_LIMIT
and ZALENIUM_SELENIUM_CONTAINER_MEMORY_LIMIT
. An example of values for these environment variables are:
CPU Value 20000000 = 0.2 cpu Memory Value 536870912 = 512mb
CPU Value 100000000 = 1 cpu Memory Value 1073741824 = 1GB
Using the ZALENIUM_SELENIUM_CONTAINER_CPU_LIMIT
and
ZALENIUM_SELENIUM_CONTAINER_MEMORY_LIMIT
environment variables.
Remote Debugging
ZALENIUM_EXTRA_JVM_PARAMS
.
You also have to specify the port on remote host to which the debugger should connect.
In the following example we are using the port 8000
.
The last key
suspend
can have two values. The value y
means that the application will
be suspended until any remote debugger is connected. As the scripts/zalenium.sh script includes a 1 minute
timeout for selenium hub to has been started you should increase these timeout when using suspend=y
and rebuild your image. In the following example the timeout has been increased to 30 minutes:
Use the value y
to debug start up logic.
The value
n
means that the application will not be suspended for any remote debugging.
Don't forget to check if you IDE is able to use remote debugging and is properly configured. That means setting the correct host and port in your IDE Debug Configuration.
More Configuration Parameters
Name | Default | Description |
---|---|---|
--desiredContainers |
2 | Number of nodes/containers created on startup. |
--maxDockerSeleniumContainers |
10 | Maximum number of docker-selenium containers running at the same time. |
--sauceLabsEnabled |
false | Start Sauce Labs node or not. |
--browserStackEnabled |
false | Start BrowserStack node or not. |
--testingbotEnabled |
false | Start TestingBot node or not. |
--cbtEnabled |
false | Start CrossBrowserTesting node or not. |
--lambdaTestEnabled |
false | Start LambdaTest node or not. |
--startTunnel |
false | When a cloud testing platform is enabled, starts the tunnel to allow local testing.
See the documentation for each provider on usage and any necessary Selenium capabilities. The local identifier used when creating the tunnel iszalenium .
|
--videoRecordingEnabled |
true | Sets if video is recorded in every test. |
--screenWidth |
1920 | Sets the screen width. |
--screenHeight |
1080 | Sets the screen height. |
--timeZone |
"Europe/Berlin" | Sets the time zone in the containers. |
--debugEnabled |
false | Enables LogLevel.FINE. |
--logJson |
false | Output logs in json format |
--logbackConfigFilePath |
logback.xml | Path to a custom logback config file. |
--seleniumImageName |
"elgalu/selenium" | Enables overriding of the Docker selenium image to use. |
--gridUser |
- | Allows to specify a user to enable basic auth protection. --gridPassword must also be provided. |
--gridPassword |
- | Allows to specify a password to enable basic auth protection. --gridUser must also be provided. |
--maxTestSessions |
1 | Maximum amount of tests executed per container. |
--keepOnlyFailedTests |
false | Keeps only failed tests on the dashboard (you need to send a cookie with the test result). |
--retentionPeriod |
3 | Number of day's a testentry should be kept in dashboard before cleanup. Note: You need to manually push the Cleanup button or create a cronjob (https://github.com/zalando/zalenium/issues/274#issuecomment-374215984) |
Environment Variables
Any of these environment variables can be passed to Zalenium like this:
Name | Default | Description |
---|---|---|
SAUCE_LABS_URL |
http://ondemand.saucelabs.com:80 | Url that will be used to connect to the SauceLabs cloud service. |
SAUCE_LABS_API_URL |
https://saucelabs.com/rest/v1/ | Url that will be used to connect to the SauceLabs API. |
TESTINGBOT_URL |
http://hub.testingbot.com:80 | Url that will be used to connect to the TestingBot cloud service. |
BROWSER_STACK_URL |
http://hub-cloud.browserstack.com:80 | Url that will be used to connect to the BrowserStack cloud service. |
CBT_URL |
http://hub.crossbrowsertesting.com:80 | Url that will be used to connect to the CrossBrowserTesting cloud service. |
LT_URL |
https://hub.lambdatest.com | Url that will be used to connect to the LamdaTest cloud service. |
NEW_SESSION_WAIT_TIMEOUT |
600000 | Time in ms that a session will be kept in the queue before it timesout while waiting for a node to be available. |
WAIT_FOR_AVAILABLE_NODES |
true |
If --maxTestSessions is specified with a value > 1, a cleanup task of 2-3 seconds will be executed between tests.
A new request normally will wait for that task to be completed and reuse the proxy, which is faster to create a new proxy from
scratch. If this env var is set to false, the request won't wait and create a new proxy when available.
|
TIME_TO_WAIT_TO_START |
180000 | Time in ms to wait for a proxy to start. When a proxy takes longer than that, it is assumed that its creation failed and a new one will be created. This is useful for Kubernetes environments, where eventually a pod could take longer to be created. |
MAX_TIMES_TO_PROCESS_REQUEST |
30 |
When a request is received and no proxy is available, a new one will be created and the request will be put back
in the queue to wait for a proxy to be available. Zalenium will check up to MAX_TIMES_TO_PROCESS_REQUEST
times if there is a proxy available for that request, if there was no proxy available after all the times it
checked, a new one will be created.
|
CHECK_CONTAINERS_INTERVAL |
5000 |
Time interval in ms where the current running containers/proxies are checked for their status. Every
CHECK_CONTAINERS_INTERVAL ms a check will be performed to see if containers need to be created,
if some can be shutdown and if some others are idle.
|
ZALENIUM_PROXY_CLEANUP_TIMEOUT |
180 |
Time in seconds to wait for the completion of the cleanup task executed between tests. If the cleanup task
takes longer than ZALENIUM_PROXY_CLEANUP_TIMEOUT , the Grid will be considered to be overloaded
and the proxy will be terminated.
|
SEL_BROWSER_TIMEOUT_SECS |
16000 |
Time in seconds for browserTmeout , maps to the same parameter in default Selenium Grid.
|
NGINX_MAX_BODY_SIZE |
300M | Max body size accepted by nginx. Can be usefull if selenium test try to upload file bigger than 300M. |
One line starters
Zalenium one-liner starter
Install and start
Install and start a specific version
Cleanup
Starting Zalenium with Docker Compose
Click here to display the example.
`
Beware that docker-compose --abort-on-container-exit
might render the video
unusable, the finalization of the file cannot happen. In this case, stopping Zalenium in case of the certain
conditions must be automated in another way.
Docker Swarm
Before starting
Setup a docker swarm with at least two nodes.
Constellations
- One manager and multiple workers. The hub will run on the manager and the created browser containers will run on the workers.
- A high available docker swarm with multiple managers.
Images
Pull images:
Run Zalenium
Provide a docker-compose.yml file and deploy it:
Info: Use an appropriate name for STACK
.
docker-compose.yml example:
Video recording and logs are currently not supported, but we hope to re-enable this feature with docker swarm.
Network
The created overlay network must be passed as argument --swarmOverlayNetwork
to zalenium,
which will actually switch Zalenium to Docker Swarm mode.
Make sure passing the network name with its stack name as prefix.
In our example we named our network “zalenium” and the stack was named “STACK” so the network
will have the name "STACK_zalenium"
, which we passed to "--swarmOverlayNetwork"
.
Options
If you want browser containers only deployed on workers set SWARM_RUN_TESTS_ONLY_ON_WORKERS=1
as environment variable.
Technical Information
Synchronized docker operations
Docker operations run in synchronized blocks to prevent stale browser containers remain forever.
see also:
One service per test session
For each test session we deploy a new service that will create a browser container to run tests.
Working with one service and adapt the number of replicas does not work because we can’t control which browser containers will be removed when decreasing replicas. It can and will happen that docker will remove a browser container with a running test to fulfill number of replicas.
Known Errors
Executed tests run into following forwarding errors:
was terminated due to FORWARDING_TO_NODE_FAILED
cannot forward the request unexpected end of stream on Connection
The docker swarm seems to be overloaded. Try to reduce--maxDockerSeleniumContainers
to unload your docker swarm system. A good value is the number of all cpu cores available in the docker swarm.
Zalenium has support for Kubernetes, these instructions will give you an overview of how to get it running. If you find something that needs to be improved, please give us a hand by creating a pull request or an issue.
Kudos to @pearj for helping Zalenium work in Kubernetes.
Quick start with Minikube or Minishift (for Openshift)
You can use Minikube to deploy locally and get a first impression of Zalenium in Kubernetes. Before starting, you could follow the Hello-Minikube tutorial to get familiar with Minikube and make sure it is properly installed.
You will also need Helm, the standard package manager for Kubernetes.
Thanks to @gswallow and @arnaud-deprez for contributing to Zalenium with the Helm chart.
After starting Minikube locally, follow these steps:
- (Optional) To save time, switch to the Minikube docker daemon and pull the images.
- Pull the Zalenium repo to use the files from the Kubernetes folder
- Create the deployment in Minikube
- Go to the Minikube dashboard and check the deployment, also open the Grid Console
That’s it, you can point your tests to the url obtained in the last step.
More implementation details and deployment How Tos
Zalenium integrates with Kubernetes using the fabric8 kubernetes-client and openshift-client and the initial support was developed on OpenShift, but should be backwards compatible with vanilla Kubernetes and has been tested on Minikube.
Service Account
Zalenium uses a service account that is automatically mounted by Kubernetes, it is used to create Selenium pods and their related services.
It is a good idea to create a separate service account for specific use by Zalenium, since now most of Kubernetes setup
uses role based authentication by default, meaning that the service account will need a
Role
or ClusterRole
created that has the necessary privileges to access the parts of
the Kubernetes API that it needs to.
By default, the helm chart will create a ServiceAccount
with an appropriate Role
and RoleBinding
at the namespace level.
You can see the Role
that will be created here.
If your cluster does not have RBAC enabled, you can disable it with --set rbac.create=false
and --set serviceAccount.create=false
.
You can also use a predefined ServiceAccount
with --set rbac.create=false
and --set serviceAccount.create=false
and --set serviceAccount.name=foo
.
More options are available and explained in the chart README.
App label
Zalenium relies on there being an app="something"
label that it will use to locate Services
and during Pod
creation.
This means that you can have multiple zalenium deployments in the same kubernetes namespace that can operate independently
if they have different app labels.
A good default to use would be: app=zalenium
.
Overriding the Selenium Image
For performance reasons it could be a good idea to pull the selenium image, elgalu/selenium
, into a local registry,
especially since the image will need to be available on potentially any kubernetes node.
For more details about overriding the Selenium image, click here
This command will automatically import
elgalu/selenium
into the OpenShift
registry at delivery/selenium:latest
updating it on a schedule.
This would then be available at 172.23.192.79:5000/delivery/selenium:latest
in the OpenShift registry for example.
To use that image, specify
--set hub.seleniumImageName="172.23.192.79:5000/delivery/selenium:latest"
when
processing your Helm templates.
Auto-mounting the shared folder
Like the Docker version of Zalenium, the Kubernetes version can automatically mount shared folders, the only catch is
that when you are using persistent volumes you need to make sure that the Access Mode
is set to ReadWriteMany
,
otherwise the selenium nodes will not be able to mount it.
Click here for more details
volumeMounts
for the Zalenium container when
it starts up, if it finds mounted volumes it will copy the volume mount
information and the linked volume
information when it creates a
Selenium pod.
Managing Resources
Kubernetes has support for managing how much resources a Pod is allowed to use. Especially when using video recording it is highly recommended to specify some resource requests and/or limits otherwise users of your Kubernetes cluster may be negatively affected by the Selenium pods.
Click here for more details
Name | Environment Variable | Example |
---|---|---|
CPU Request | ZALENIUM_KUBERNETES_CPU_REQUEST |
250m (25% of a CPU core) |
CPU Limit | ZALENIUM_KUBERNETES_CPU_LIMIT |
500m (50% of a CPU core) |
Memory Request | ZALENIUM_KUBERNETES_MEMORY_REQUEST |
1Gi (1 Gibibyte) |
Memory Limit | ZALENIUM_KUBERNETES_MEMORY_LIMIT |
Probably best to leave empty, because Kubernetes will kill the container if it exceeds the value. |
Openshift DeploymentConfig
If you are using Openshift, you might would like to use Openshift DeploymentConfig instead of Kubernetes Deployment. Check here for more information on their difference
Click here for more details
Usage
Live Preview
Displaying the live preview
- Go to http://localhost:4444/grid/admin/live
- You can replace
localhost
for the IP/machine name where Zalenium is running
- You can replace
- Auto-refresh, add
?refresh=numberOfSeconds
to refresh the view automatically.
- E.g. http://localhost:4444/grid/admin/live?refresh=20 will refresh the page every 20 seconds.
Showing the test name on the live preview
Having a name
capability with the test name will display it in the live preview.
See test name
for more information.
Filtering tests by build name
If more than one person is using the same instance of Zalenium, with a build
capability in your tests, the live preview can be filtered to show only the tests that belong to a specific build.
Pass ?build=myTestBuild
at the end of the url. E.g.
http://localhost:4444/grid/admin/live?build=myTestBuild
See more details at build name
.
Filtering nodes by active sessions
If you want to display only the busy Selenium nodes, you can filter the live view with the following parameter:
Pass ? Only_active_sessions = true
at the end of the url. E.g.
http://localhost:4444/grid/admin/live?only_active_sessions=true
Dashboard
- Go to http://localhost:4444/dashboard
- You can replace
localhost
for the IP/machine name where Zalenium is running
- You can replace
- Check all the recorded videos and aggregated logs after your tests completed
- Click on Cleanup to remove all videos and logs from the local drive and the dashboard
- Also reset the dashboard via
http://localhost:4444/dashboard/cleanup?action=doReset
or cleanup viahttp://localhost:4444/dashboard/cleanup?action=doCleanup
- Also reset the dashboard via
- You can search tests by query parameter
q
- E.g.
http://localhost:4444/dashboard/?q=test01
- E.g.
Test Configuration Options
Test name
Click for details.
name
capability with the test name will do two things; it will
be displayed in the live preview to help you identify where your test is running, and the video file will also
use it in the file name. Example code in Java for the capability:
Build Name
Click for details.
Idle Timeout
Click for details.
idleTimeout
capability in your test. Example code in Java for the
capability (it sets the idleTimeout
to 150 seconds):
Screen Resolution
Click for details.
screenResolution
with the desired value. E.g. screenResolution=1280x1024
. Also supported for
the same purpose resolution
and
screen-resolution
. Example code in Java for the capability
screenResolution
Disable Video Recording
Click for details.
recordVideo=false
capability and no video will be recorded. Example code
in Java for the capability recordVideo
Time Zone
Click for details.
Europe/Berlin
,
just pass a capability tz
with the desired value. E.g.
tz=America/Montreal
Example code in Java for the capability
tz
.
Test File Name Template
Click for details.
testFileNameTemplate
capability will save logs and video recording with file name format you prefer.
Resulting file name can have invariable and variable text. You can find the list of variable text below:{proxyName} - Zalenium|SauceLabs|BrowserStack|LambdaTest
{testName} - The one added as "name" on capabilities, otherwise a session key
{browser} - The browser name
{platform} - OS where test runs
{timestamp} - Timestamp of test initialization
{seleniumSessionId} - The external sessionId provided to the test runner
{testStatus} - Test result: COMPLETED|TIMEOUT|SUCCESS|FAILED
E.g.
myID_{browser}_{testStatus}
will result on video file name as "myID_chrome_COMPLETED.mp4".Default file name template is: {proxyName}_{testName}_{browser}_{platform}_{timestamp}_{testStatus}
You can use '/' as separator in order to get the videos organized into different folders folder
Example code in Java for the capability
testFileNameTemplate
.
Marking the test as passed or failed
Click for details.
zaleniumTestPassed
with a value of true
(if the test passes) or false (if the test fails).
This could be done in the after method where you already know if the test passed or failed. Here is an example in Java:
Referencing test steps in the recorded video
Click for details.
zaleniumMessage
. Here is an example in Java:
Set browser language (works only with Chrome)
Click for details.
ChromeOptions
variable with the language argument. Example code in Java :
Send video and logs to some external system for storage
Thanks adrichem for implementing this feature! More details in issue 430.
Click for details.
Setting an environment variable tells Zalenium where to send the artifacts to the store: If that environment variable does not exist, then the local dashboard will be used and Zalenium will not send the artifacts to the store.The tester can tell Zalenium to send arbitrary JSON metadata together with the files. Here's a snippet of C# code that does that: Here is an example of the endpoint that can receive the requests.
Change video recording status while in session
Click for details.
zaleniumVideo
with a value of true
(to enable recording)
or false (to disable recording). Disabling recording while it is originally enable will result in a new video file. This can be useful
when you have multiple tests in one session and want to split up each test in its own file. This feature is only available with elgalu/selenium.
Here is an example in Java:
Change test file name while in session
Click for details.
zaleniumTestName
with any value.
This can be useful when coupling with zaleniumVideo
to give each split video a custom name. Here is an example in Java:
Waiting for Zalenium to be ready
A simple way to check if Zalenium is ready to receive test requests is to use the built-in status url that Selenium Grid already provides: http://localhost:4444/wd/hub/status
If the endpoint returns an HTTP code 200 and the value for the key ready
is true
, it means that Zalenium is ready
to receive tests requests. Here is an example how the JSON payload looks like:
`
You could grep
the value using jq
in a bash function like this:
If you want to know the status of the GRID with a higher level of detail, you can use the following path: http://localhost:4444/grid/status
Grid available but without attached node:
Grid available with at least one attached node:
Grid available with all nodes requested at the attached init:
Cleaning all active sessions
A simple way to clean all active grid sessions, when using debugging with orphaned sessions for example, is to call the following url: http://localhost:4444/grid/sessions?action=doCleanupActiveSessions
If the endpoint returns an HTTP code 200 and the value for the key SUCCESS
, it means that all active sessions have been deleted.
How
Zalenium works conceptually in a simple way:
- A Selenium Hub starts and listens on port 4444.
- One custom node for docker-selenium
- If a cloud testing integration is enabled, a cloud proxy node to support a cloud provider (Sauce Labs, BrowserStack, TestingBot, LambdaTest) will register to the grid.
- A test request is received by the hub and the requested capabilities are verified against each one of the nodes.
- If docker-selenium can fulfill the requested capabilities, a docker container is created on the run, and the test request is sent back to the hub while the new node registers.
- The hub acknowledges the new node and routes the test request with to it.
- The test is executed and the container is disposed after test completion.
- If docker-selenium cannot fulfill the requested capabilities, it will processed by one of the enabled cloud testing platforms.
Project Versioning
- To make life easy for people who want to use Zalenium, we are now using as a version number the Selenium version being supported.
- The major-minor version combined with the patch level will indicate the Selenium version being supported. E.g.
- When a release is
3.8.1a
, it supports Selenium 3.8.1 - The badge above shows the latest image version
- Alias for the latest images,
dosel/zalenium:latest
- When a release is
Contributing
Contributions
Thank you for your interest in making this project even better and more awesome. Your contributions are highly welcomed.
If you need help, please open a GitHub Issue in this project. If you work at Zalando reach out to us at team-tip.
Report a bug
Reporting bugs is one of the best ways to contribute. Before creating a bug report, please check that an issue reporting the same problem does not already exist. If there is an such an issue, you may add your information as a comment.
To report a new bug, open an issue that summarizes the bug and set the label to “bug”.
If you want to provide a fix along with your bug report: That is great! In this case please send us a pull request as described in section Contribute Code.
Suggest a Feature
To request a new feature, open an issue and summarize the desired functionality and its use case. Set the issue label to “feature”.
Contribute Code
This is a rough outline of what the workflow for code contributions looks like:
- Check the list of open issues. Either assign an existing issue to yourself, or create a new one that you would like work on and discuss your ideas and use cases.
- Fork the repository
- Create a topic branch from where you want to base your work. This is usually master.
- Make commits of logical units.
- Write good commit messages (see below).
- Push your changes to a topic branch in your fork of the repository.
- Submit a pull request
- Your pull request must receive a from two maintainers
Thanks for your contributions!
Commit messages
Your commit messages ideally can answer two questions: what changed and why. The subject line should feature the “what” and the body of the commit should describe the “why”.
When creating a pull request, its comment should reference the corresponding issue id.
Have fun and enjoy hacking!
Code of Conduct
We have adopted the Contributor Covenant as the code of conduct for this project:
http://contributor-covenant.org/version/1/4/
Building and Testing
If you want to verify your changes locally with the existing tests (please double check that the Docker daemon is running):
- Unit tests
- Building the image
- Running the image you just built
- Running the integration tests with Sauce Labs or BrowserStack or TestingBot or CrossBrowserTesting or LambdaTest. You will need an account on any of those providers to run them (they have free plans).
FAQ
Frequent Asked Questions
Why do I get 502 (and similar) when running tests and using video?
Usually, when no enough CPU resources are available for video recording it is possible to get this error codes. Check this issue and the performance section.
Docker network setting enable_icc causes Zalenium to fail silently
This is a known issue with containers running browsers, please see this issue for more information.
Browser can’t resolv host names
The container are using Google’s nameserver by default (8.8.8.8 and 8.8.4.4). If they are not reachable from within your network, you may use your host machine’s or a specific configuration by starting zalenium with “-v /etc/resolv.conf:/etc/resolv.conf -v /etc/resolv.conf:/tmp/node/etc/resolv.conf”.
Links
Integrated Cloud Testing solutions
Thanks to the open source accounts we got, we have integrated so far:
Open Source Licenses
Thanks to JProfiler for giving us an open source licence of their product.
Links about (or mentioning) Zalenium
Blog Posts
- 14.02.2017 - Zalenium: A Disposable and Flexible Selenium Grid Infrastructure (English)
- 22.03.2017 - Zalenium: A Disposable and Flexible Selenium Grid Infrastructure (English)
- 04.05.2017 - Selenium Conf Gets a Dose of Zalenium (English)
- 23.05.2017 - Travis and WDIO - Breaking out of the Black Box (English)
- 29.05.2017 - Selenium WebDriver – Disposable Selenium Grid Infrastructure Setup using Zalenium (English)
- 14.06.2017 - How to use selenium when using docker container (English)
- 17.07.2017 - Selenium Testing With 2-Way Authentication - Background Intro (English)
- 21.07.2017 - Web UI Testing Made Easy with Zalenium (English)
- 15.08.2017 - Zalenium - Selenium Grid facil, rápido y enriquecido (Spanish)
- 31.08.2017 - Zalenium 容器化扩展Selenium Grid (Chinese)
- 30.09.2017 - Managing Selenium Node using Zalenium (English)
- 13.10.2017 - Running Selenium tests with Jenkins Pipelines and Zalenium (English)
- 15.10.2017 - Comment mettre en place vos plateformes de tests automatisés en un clic grâce à Docker (French)
- 07.12.2017 - LINE STOREにおけるテスト自動化の取り組み (Japanese)
- 10.12.2017 - E2Eテストのboilerplateを書きました(SeleniumとZalenium) (Japanese)
- 18.12.2017 - ZaleniumをKubernetes/GKEで動かす (Japanese)
- 26.01.2018 - zaleniumの起動・停止制御を行うスクリプト (Japanese)
- 10.02.2018 - zalenium 应用 (Chinese)
- 10.03.2018 - Auto Scale Selenium Hub with Zalenium (video) (English)
- 04.04.2018 - Tried Zalenium to run Selenium tests on scalable containers (English)
- 04.04.2018 - Zaleniumさんに動的にコンテナを立ち上げたり捨てたりしてもらいながらSelenium(というかGebだけど)のテストを実行してその録画を見る (Japanese)
- 05.2018 - Rethink Your Automation Setup (English)
- 23.05.2018 - Setting up RSpec with Zalenium – a Selenium grid Docker solution (English)
- 24.06.2018 - Dynamic Selenium Grid using Zalenium with Diego Molina (English)
- 29.06.2018 - What is Zalenium (video) (English)
- 05.07.2018 - Running Selenium grid with Zalenium in Docker container (English)
- 07.07.2018 - Stable and Elastic Selenium Grid using Zalenium (Docker based) (English)
- 29.08.2018 - Zalenium, the Zalando Selenium Grid (English)
- 12.10.2018 - Zalenium alternatywa dla Selenium Grid (Polish)
- 20.11.2018 - Zalenium Dockerized Selenium Grid (English)
- 01.12.2018 - Auto Scale Selenium Hub with Zalenium (English)
- 04.12.2018 - Zaleniumのダッシュボードを便利に使う (Japanese)
- 05.12.2018 - ZaleniumをKubernetesで動かして並列テストさせる話 (Japanese)
- 11.12.2018 - How To Get Started With Zalenium Docker Grid (Video) (English)
- 04.16.2019 - メルカリWeb版のUIテスト自動化で目指している世界と、そのために作った Selenium Grid・Zalenium 環境 on Azure Kubernetes Service(AKS) (Japanese)
Events
- 20.07.2016 - Docker Selenium & Zalenium, Video Recording (Berlin, Germany)
- 05.04.2017 - Zalenium - SeleniumConf Austin 2017, Presentation Slides, Video Recording (Austin, USA)
- 27.04.2017 - Setting up a disposable Selenium Grid on Linux in 3 steps (Fort Lauderdale, USA)
- 10.05.2017 - Android & Selenium Grid with Docker @ Zalando adtech lab (Hamburg, Germany)
- 15.09.2017 - Zalenium: How to run Selenium scripts using Docker and Selenium Grid (Cairo, Egypt)
- 28.09.2017 - Parallel Selenium Test With Docker, Presentation Slides, Video Recording (Tokyo, Japan)
- 29.11.2017 - Zalenium, a flexible and reusable Selenium Grid. (Barcelona, Spain)
- 08.12.2017 - Scaling Selenium, Heisenbug (Moscow, Russia)
- 13.02.2018 - Selenium Grid and Zalenium (Berlin, Germany)
- 15.02.2018 - Intro to Selenium and Selenium Grid (Madrid, Spain)
- 27.02.2018 - ¿Cómo ejecutar scripts de Selenium usando Docker (Zalenium)? (Itagüi, Colombia)
- 05.04.2018 - Selenium under the hood, and its challenges (Berlin, Germany)
- 09.05.2018 - Google I/O Extended 2018, Portugal Testing Tour, Selenium under the hood, and its challenges (Braga, Portugal)
- 09.05.2018 - Zalenium - How to run Selenium Script using Docker and Selenium Grid (Berlin, Germany)
- 10.05.2018 - Portugal Testing Tour, Selenium under the hood, and its challenges (Porto, Portugal)
- 17.05.2018 - Selenium under the hood, and its challenges (Hamburg, Germany)
- 19.07.2018 - Como criar e executar testes paralelos web usando Selenium e containers - Elias Nogueira (Sao Paulo, Brazil)
- 20.09.2018 - Be flexible with Zalenium, a dockerized Selenium Grid infrastructure (Athens, Greece)
- 27.09.2018 - DevOps Playground Edinburgh: Auto-Scaling Selenium with Docker and Zalenium (Edinburgh, Scotland)
- 18.10.2018 - Manage your cloud costs with Zalenium and Selenium-as-a-Service (Cary, North Carolina, USA)
- 23.10.2018 - StutttgartJS @ My Porsche (Ludwigsburg) (Ludwigsburg, Germany)
- 30.10.2018 - DevOps Playground Edinburgh: Continuous Testing with Jenkins and Zalenium (Edinburgh, Scotland)