selenoid (1)


Have you heard of our lord and savior Selenoid?

Last few weeks more and more colleagues at work have been asking for how to work with Selenium. Now i’m of the opinion that System tests (that selenium often are) are expensive, fragile, take time and are mostly a waste of that time. This is because people tend to write WAY more system tests than they would need and really overdo it.

Unit and Integration tests by far more important before we’re putting all of our test-coverage in a system test. With that said, System tests absolutely have their place in a real DevOps environment. As long as you don’t see it as a replacement for manual testing, but more of an indication of the health of your deployment. And what better way to get that in place than using the most populat framework for automating the browser: Selenium.

Selenium

Selenium has bindings in most languages out there which is really neat.
The tricky thing with it is that the framework is decoupled from the drivers that interacts with a particular browser. This makes a’lot of sense because it is easier to provide an interface or protocol (selenese) for the browsers to allow browser vendors to bind their own functionality to match it. So Google Chrome, Mozilla Firefox and Opera, IE has their own drivers, some mobile providers like the android and IOS platforms also have driver implementations that can speak selenese for their systems.

This has a consequence for us as developers that we need to mix and match multiple versions of browsers versions with driver versions and operating systems. This makes selenium tests tricky to set up in a sense that isn’t platform dependent, and as a consequence the CI environment will not match the dev-environment making this kind of testing unreliable.

There’s light in the end of the tunnel though as there’s another kind of driver, the Remote Web Driver. What this does is decouple the need to handle drivers to a server. The driver connects to a service or selenium grid that provides a set of capabilities for which browsers and browser-versions it supports. That way the test does not need to consider setting up the infrastructure For running a selenium test, because that’s the concern of the grid.

So, at work i started looking into setting one of these selenium grids up to help out my colleagues. During that research i stumbled into this video from 2017 SeleniumConf in Berlin about a project called Selenoid.

You can watch it by clicking here.

Hello Selenoid

Selenoid is a project that utilizes Docker images to spin up standalone environments for each running remote selenium session. It is written in Go and also comes with a neat, optional, UI. The UI is able to display the currently running sessions, both its server logs and allow the user to interact with the browser over VNC. This is a disruptor that is in the same market as Saucelabs and Browserstack and makes it possible to get the same scalability and flexibility as these expensive platforms but for free and deployed on your own docker-environment.

Suddenly it has become really easy to spin up a server that takes care of all that is cumbersome with Selenium. Meaning matching driver to browser per environment problem that came with the original java-based selenium server. It also uses a fourth of RAM as the Java version, as claimed in the video.

I really believe Selenoid is the future of running Selenium clusters, i’ve tried it out for some time now and i’m really blown away. So if you are thinking about running a Selenium Server then you should definitely check it out

Vagrant and Selenoid

I’m not a big fan of having a bunch of docker images on my workstation as they usually end up cluttering the machine when i stop using them. So i put sub-projects with docker or other Linux-based experiments in Vagrant-dev environments. Vagrant is a wrapper on top of Virtualbox and makes it real easy to have a completely virtualized environment that can be automatically setup, provisioned and torn down every day. So i wrote a Vagrantfile that downloads an ubuntu/trusty image and provisions Docker, starts Selenoid and Selenoid UI.

I also threw in an example on how to run Remote Selenium tests. You can find it and the vagrantfile and how to run it on my GitHub: Selenoid-Vagrant

private WebDriver browser;

@Before
public void setUp() throws Exception {
    DesiredCapabilities abilities = DesiredCapabilities.chrome();
    abilities.setCapability("version", "61.0");
    this.browser = new RemoteWebDriver( new URL("http://localhost:4444/wd/hub"), abilities);
    this.browser.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
    this.browser.manage().window().setPosition(new Point(220, 10));
    this.browser.manage().window().setSize(new Dimension(1000,650));
}

@Test
public void testSimple() throws Exception {
    this.browser.get("http://www.google.com");
    assertEquals("Google", this.browser.getTitle());
}

@After
public void tearDown() throws Exception {
    this.browser.quit();
}