So I have tested an appium script and it's running fine but I want to run it with selenium grid so I can run this on a different machine but I am not clear on if I need to keep the hub machine always active or it can be powered off after a certain while or if I can make another hub on my node machine. If an alternative means is possible for achieving this can I know too? Thank you.
Related
I have the following Dockerfile which will build a Selenium server
FROM selenium/standalone-firefox:3.4.0-chromium
FROM selenium/standalone-chrome
USER root
ENV NODE_ENV test
RUN mkdir -p /usr/local/cdt-tests/csv-data
COPY ./csv-data /usr/local/cdt-tests/csv-data
USER seluser
obviously the two FROM statements is incorrect => How can I create a Selenium server container that has both a Chrome driver and Firefox driver for Selenium. As far as I can tell, the selenium/standalone-firefox:3.4.0-chromium image only works for Firefox.
There is no inheritance type setup for Dockerfiles like you are suggesting.
To implement a combined build you would need find the common FROM ancestor of the standalone-firefox and standalone-chrome, which is selenium/node-base and create your own Docker file to reapply all the build steps that selenium/standalone-chrome applies. Then keep it in sync whenever Selenium update their builds.
Dockerfile Hierarchy:
selenium/node-base
/ \
selenium/node-chrome selenium/node-firefox
| |
selenium/standalone-chrome selenium/standalone-firefox
The problem is these builds have been designed to be seperate, so there is significant overlap in the variables and settings that the images use that you would also need to unpick in your custom build to control and run both chrome and firefox at the same time. You will probably end up having to do everything from scratch.
Selenium Grid
Running individual Selenium grid node's behind a grid hub is the standard way to do multi browser testing from a single endpoint. You can run Firefox, Chrome or Phantom JS nodes in Docker or connect standard nodes from anywhere else.
Poor mans grid
You can always run a container for Chrome and Firefox on seperate ports and point the same test suite at a different port if setting up a Grid is a lot of work for the simple case of running some tests against each browser.
You cannot merge two docker files likes that. You can use one as a base for your docker file, then copy the important bits from the other into your one.
However you shouldn't really need to. There are images out there with multiple browsers and drivers included. Or better, you could set up a grid with the hub image and some driver images.
You might even consider a library such as Serenity or a product such as Katalon, both of which do it all for you. There is even a Katalon docker image designed for use in CI: it's command-line + headless only, but that's all you need for most of your CI-driven regression testing.
Could someone please help me understand the difference between the remote control server in Selenium Grid 1 and the remote control server in Selenium Grid 2. From what I've read, one of the main differences between the versions is that version 2 of Selenium Grid was merged with Selenium Remote Control. Is this the same remote control as Selenium 1, that was responsible for proxy injection? as I thought this had been deprecated.
This is as of Selenium 3.4.0
We now have two separate artifacts.
For example if you head down to the Selenium downloads URL you would notice the following two artifacts
selenium-server-standalone-3.4.0.jar - This is the Grid (or Grid2 as you call it) as we know. This standalone jar can work in 3 modes viz.,
Hub - It acts as the hub standing in between your test and the actual node that gets the work done. Kind of like a postman/mailman and a match maker.
Node - This is the actual place where all the action happens. When running in this mode, it is responsible for getting automation requests from the tests routed via the Hub and opens up browsers, performs UI actions etc.,
Standalone - This is pretty much the same as Node but just that it doesn't require a Hub to route the automation test traffic to it. Tests can directly point at the Standalone and then start running. I believe this is perhaps the kind of setup that third party execution environment providers such as SauceLabs maybe using. (This is just a hunch, I don't know for sure).
selenium-html-runner-3.4.0.jar - This is where all the legacy stuff (or Selenium RC as you call it) has moved into. So if you had a html test suite that you created by recording a UI flow using Selenium IDE and wanted to run them from a command line (Note that you can always execute a html test suite from within the Selenium IDE and don't need anything extra), you would use this.
There is nothing called as Selenium Grid1 anymore. There's only Selenium Grid2 (which is the re-engineered version of Grid1).
The Selenium RC support exists only as a stop gap solution with no maintenance as part of selenium-html-runner-3.4.0.jar. This has been officially deprecated and there's no support for issues that surface on this.
The expectation is that if one were to be using Selenium and building new tests, then one should be directly using only the WebDriver APIs (which is Selenium2) and not fall back to using DefaultSelenium APIs (which is Selenium1)
Hope that helps!
I have Chrome working headless via a Selenium server by running xvfb bound to DISPLAY:10 and then running Selenium with a DISPLAY=:10 webdriver-manager start. So that's all fine.
I also have Chromedriver running directly from protractor by specifying directConnect: true in my protractor.conf.
What I'd like to do is a combination of the two, ie. run chromedriver directly (NO SELENIUM!), but somehow instruct it to run headless on DISPLAY :10.
In terms of topology, everything is run on the developer's PC. There are no servers involved. In a comment below, I mention a node server: this is being used to launch protractor instead of the more usual launching from the command line. I want protractor to be running on DISPLAY:0 so I can see its output, test failures etc. When it spawns chrome using chromedriver, I want chrome to be running on DISPLAY:10. My reason for doing this is that I want the chrome window to be bigger than my physical screen. See How can I screenshot the full height of a mobile form factor? for background.
I'm guessing the topology is like this:
Box A: xvfb, DISPLAY=:10, Selenium Server, chromedriver
Box B: DISPLAY=:0, node, protractor (directConnect: true), chromedriver
Box C: test runner.
I don't know how else it could be laid out, given that DISPLAY is an environment variable, not a parameter to be passed.
In which case, assuming you don't want a separate xvfb installed on Box B, and A is reachable (plus a decent connection) from B, the solution is simply to set:
DISPLAY=boxAHost:10
on Box B.
If A isn't reachable from B, it might be simplest to just duplicate the xvfb setup on both A and B, and have DISPLAY=:10 on both.
I had a "Doh!!!" moment of zen and the whole thing is much easier that I thought it would be.
I had conflated the stdout of node/protractor (which I want on my screen) with the X display of chrome (which I want headless on DISPLAY:10). Of course they are totally different!!!!
Simply prefixing protractor with DISPLAY=:10 eg.
DISPLAY=:10 protractor /installation_test/conf-c-direct-noserver.js
or, in my case since I'm running a node server which in turn spawns protractor, ...
DISPLAY=:10 npm start
So protractor runs in my terminal and I can watch stdout, whereas the DISPLAY=:10 is inherited down through the call layers and is eventually seen and understood by Chrome.
Currently we are running the selenium grid on a Windows 7 vm and we have about 10 other win 7 vms for the nodes. We periodically run into some problems where the node stops working and just needs to be restarted. We also would like a periodic restart. I am curious how others are managing/ monitoring the nodes to see when something fails. Not sure if there is a way to monitor with something like Nagios?
I thought for restarting that I could try to build the node jar as a reservice and just have a schedule to reboot it once a month. Thoughts? Do I need to elaborate some more? Thanks
You can try selenium-grid-extras. Its been open sourced by groupon, I believe. From their git hub page:
This project is designed to help you manage your Selenium Grid installation by giving you control over the Grid Hub machine and Grid Node machine. This is very useful in cases when Internet Explorer Driver crashes, and you need to kill the iedriver.exe so that next test can start and not fail.
Link to the page - https://github.com/groupon/Selenium-Grid-Extras
Does anyone know how to run a selenium test suite from a selenium grid.
I know you can do it programatically with a single test, but I was wondering if there was an easy way to do it with a full test suite.
Something like java -jar selenium-server.jar -host -htmlSuite .
Thanks for the help.
This page will help you a lot. It demonstrates how to set up a hub and nodes which connect to it registering their 'configurations' (what browsers/'capabilities' they have). And the last piece of the jigsaw which is having code programmatically connect to the hub and run tests on it (the hub will forward stuff to a relevant node so the tests get performed there).
No. Selenium Grid is a facility for Selenium RC users to run their tests across a variety of machines with fine-grained configurations (e.g., a particular version of a browser). As far as I know, there's no ability to specify that in the htmlSuite. If there were, you might be able to make it work. But running just a suite like this is not supported and likely never will be because that's not what it was designed for.