[Video] Set Up A Selenium Grid Less Than A Minute
Hello and welcome everybody to today’s webinar about how you can use browser BrowseEmAll in combination with Selenium Grid, or to be more precise, how you can run your Selenium tests on a dedicated testing machine, or a dedicated testing grid from your local machine, your CI server or something else that you have come up with custom. Before we get started, you will get an email with a recording of this session and all the links I talk about in a second after the session, roughly one hour after.
If during the session you have any questions of any kind, feel free to enter them in the questions panel on your GoToWebinar UI, normally to your right. At the end, we will do a Q&A session, so that I can answer your questions accordingly. Let’s take a brief look at what a Selenium Grid is all about. Normally, if you want to run your Selenium tests on your local machine, you will need to set up this directly on your machine.
You need to install Java most likely, you will need to install the different browsers you want to test against. You will need to install the Selenium Grid itself, and of course, every browser comes with its own web driver or browser driver, and you will need to have this all readily available on your machine as well. This can be quite a task to set up and more importantly, to maintain. There are steps and tools that make this easier for you, both on premise and as a server service in the cloud.
Today, we will take a look at the on premise solution mainly. Okay, so what is this Selenium Grid? The Selenium Grid allows you to run your Selenium tests not on your machine directly, but instead on multiple machines in your local network or in the cloud. What this brings to the table is that you can run your Selenium tests in parallel, which means they will run faster. You can distribute them on different machines so that for example, you can run your tests on Internet Explorer, in Windows 10 and on Micro S with the latest version of Safari, which gives you a better coverage for your different tests.
How does this work? Again, you have at base, you have your Selenium test and your Selenium code. This Selenium code does talk to a so called remote driver, which takes the URL where your Selenium Grid lives as a parameter. You also have to tell the remote driver in which browser and which browser version you want your tests to run in. This remote web driver then talks to a Selenium hub, which runs on of your distributor testing machines. The Selenium hub orchestrates the test execution.
The hub makes sure that it finds a suitable machine where you test can be executed based on the browser and operating system you define. The Selenium hub can then talk to different Selenium nodes, which run on different machines, and will automatically pick the Selenium node that is available for testing and has the correct setup installed. You can go as far as you want with that. You can just define the browser you want to run your test in and ignore the operating system, for example.
Normally, how would you set up such a hub? You would download Java, you would download the Selenium standalone server, you would start the hub in the command line, and then you have the grid available on your machine. To set up a node, you need to get a little more complicated. You will first need to create a node configuration file, which tells the node which browsers it can actually run and on which platform.
Then you can again start the node with the Java command line, and just tell in which hub it should register itself. Now, let’s take a look at how you can get this in a simpler way, without all these necessary setup steps and all the complications that come with setting up and maintaining multiple machines in your local network. With our cross browser testing to BrowseEmAll, we have an integrated Selenium Grid. You can see this here top.
Keep in mind that everything that runs here is running directly on my machine, so there’s no online component involved. It could run in an offline setup like a label, something like that. Or you could even spin up a Selenium Grid easily just while you’re sitting with you laptop online, for example. Of course, this is a rather special case here. Here, we can see we first need to configure the Selenium Grid, and we will take a look at the details here later on. For now, we just use defaults.
Then at the second step, we will need to select the browsers we want to have available in your Selenium Grid. Here there’s a wide range of browsers available, we have Microsoft Edge, we have different versions of Internet Explorer, Firefox, Google Chrome and so on and so on. After we select all the browsers we want our tests to run in, we can then certainly start click on start grid, and everything else will be taken care of by the software here in the background.
It will download all your necessary files, it will set up the hub and the different nodes if necessarily. Just after a few seconds, our grid is available and ready to use. We can take a look at Grid console here to see what we configured, and here it is. Here we can see the grid has three different browsers available. We have Firefox here, we have Google Chrome here, and we have the Internet Explorer in version 11, in version 11 as well. Then now we’re already, it’s already possible to run our Selenium tests against these browsers.
Here we can see we first have to test initialize method where we tell the remote web driver we talked about before on which URL it can contact the Selenium hub, and we tell it the capabilities which tells the hub which browser or tests are running. Here we can see the grid is currently running on the same machine as the test, so it’s local host. But you could set up a specific server in your environment that runs this Selenium hub, and you will just need to swap out the URL to whatever host name you give your dedicated server.
As a first example, we will use Chrome here as a test browser. You could specify these capabilities further. If we take a look at this object. You can tell the platform, you could tell a diversion and a lot of other things like does it accept insecure certificates, for example if you’re testing behind the self signed SSL certificate. Okay, back to our test. We also have test cleanup methods, and this test cleanup method will simply close the browser at the end of test, regardless of the fact if the test was successful or not.
It’s important to make sure that the browsers are closed every time a test finishes so that you don’t have any open instances of the browser staying there and taking up memory, and system resources in general. Finally, we come to our test method self, where we will simply navigate to a page angle test. Find an element, in this case a text box, enter the text hello here, and press the enter button at the end. Now, if we execute the test, we will briefly see Google Chrome [inaudible 00:10:47] and executing our test here.
Here it is, and you can see it’s really snappy, so we will not see that much. If we change our browser to Internet Explorer, it will be a little better to see here. Here is the Internet Explorer executing our test a little more slowly, but still you get a code but fast test response, especially if you make sure to run the 32 bit version of Internet Explorer. Okay, and just like that we can run our Selenium test on Selenium Grid without having to specify and install a lot of stuff manually.
The great thing is that as new browsers come out and new browser versions are available, we get an updated version of BrowseEmAll which doesn’t need any more maintenance, because it already brings everything necessary with it, including updated Selenium versions, for example. Let’s take another look at the application itself, because we can do much more complicated things with this. Let’s assume we already have a hub running on a dedicated server here somewhere, and we want to create another testing node which connects to this hub and can then executes tests as well.
Here, in this case, we would simply select to run as a node and tell the application where it can find the hub. Let’s say test server, for example. Then if you run the application on both of these machines, you have a grid that ties together all the browsers. For example, you could have the hub running on Windows 10, and you have a separate Mac machine somewhere where you can run this application and connect to the hub on Windows 10, which makes it possible to run your tests on Safari for example, without having to change anything in your code aside from the capabilities.
Do something like that and this would give you Safari as well. Okay, but you can configure much more than that if necessary. In the configuration, we can also see some values we might want to modify to give us the best possible test execution, and the fastest test execution. Because if you get more and more test cases, the test execution will take longer and longer, and you might want to run them in parallel as well. Here, we can see the defaults. The host name and the port where our application currently runs. The hub will run or the node will run depending on what you select.
We can also specify the browser timeout, so here for example, after 300 seconds, the hub and the nodes will automatically close any open browser sessions. If your test take longer than this, you might run into errors. The same is true for cleanup cycle, which is in milliseconds here. After 5000 milliseconds, the hub will automatically cancel any test execution that it could not find a node for. For example, if your node with Safari is busy executing tests and you create a new test which doesn’t get assigned to the node in this 5000 milliseconds, then the test will return an error, because it’s not possible to execute.
Then you can select where the log file should be saved. You can say which number of sessions you want to have. For example, you could have 10 different testing sessions at the same time, which means you should have at least 10 different browsers available to run. You can also specify your session timeout if you want. Here we have a negative value, which means there is no timeout available. You can tell the application how many instances of the same browser it can run and power it.
For example, you could tell it that it can run 10 different version, 10 different instances of Google Chrome or Firefox, or Safari. Unfortunately, Internet Explorer and Edge currently only support one instance at a time, so you won’t be able to run two instances of Internet Explorer on the same node. Of course, if you have two different nodes, then you can execute two instances of Internet Explorer at the same time.
Last but not least, here we have the session timeout, which again, times out the session if it runs longer than the specified amount of seconds. Okay, so this is the configuration in detail. You also can directly take a look at different code examples here if you want, and now you might not want to do this manually inside UI, to spin up Selenium hub or Selenium nodes. You can also do this using the command line interface, where you just specify the different browsers you want to run in your Selenium Grid, and spin up the Selenium Grid for test execution and to done again automatically after test execution.
This is the nice way to do this. For example, if you’re running the grid on the same machine as the CI server, and you only want to start it if you actually use it to save system resources here in this case. This is really all there is to it to run Selenium Grid with BrowseEmAll. In direct comparison to setting this up manually, it’s really a great way to speed up your testing process and free up resources and people to do other more important things than updating to the latest version of Selenium every two to four weeks, installing new browsers, finding issues with different drivers and stuff like that. Okay, so thank you very much for attending so far.