In this blog post series, i want to show how i normally set up my browsers and my Selenium code, in order to enable writing ‘cross-OS’, ‘cross-browser’, ‘browser-unaware’ tests. What this means: my tests can run on any OS i set up seamlessly; each test can be run on multiple browsers seamlessly; the tests do not care and are unaware of what browser they are running on. They just run and do their job, being focused on what needs to be tested, rather than on how to setup the browser or OS. OS specific setup will be done on the project level and in the class where browser initialization is defined, whereas the browser the tests will run on can be switched easily by using a configuration. This post series does not focus on using Selenium’s grid.
1.1. Have a Java project available
The first step in creating any sort of automated tests is to create an infrastructure where to gather all your test code. Meaning you need to have a code project, in which to perform all the setup you need and where to store your test code, test files, utilities code and files, and any other resource you might need in order to run the tests that you want.
All the code demonstrated in these posts is stored in a Maven project called ‘selenium-tutorial’. I will not go over what Maven is, or how to use it, but instead i will provide their website, for you to read about it in case you are new to Maven: https://maven.apache.org/index.html. The Maven project can be downloaded from its Github location: https://github.com/iamalittletester/selenium-tutorial.
A few words about how the demo project is setup: being a Maven project, upon creation a default structure was created for it, structure which is reflected in folders on the computer where you store the project. A few of these folders and their purpose are described below:
src → main → java: here you will find utility code, which is not test code but is used in the tests. In this project, in this folder, you will find several other folders, that group the utilities based on their purpose. One of these folders, ‘browser’, will contain the class where all the browser initialization and shutting down is stored.
src → test → java: this is where the tests will be stored, each in their corresponding folder. The folders help group tests by functionality or feature under test, so that you can easily find them.
src → test → resources: here, in the ‘browserBinaries’ folder, the driver binary files, described in this post, are stored, which are used for interacting with the web browsers.
1.1.1. Importing the required dependencies
In order to create and run Java Selenium tests, some external libraries need to be imported into the project. Since the examples in this post are from a Maven project, in its’ ‘pom.xml’ file, the following dependencies are declared (replace the values from the <version> tag with the latest ones available in the Maven Repository):
<dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <version>${selenium.version}</version></dependency><dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>${commons.version}</version></dependency>All things Selenium are accessible due to the import of the ‘selenium-java’ library. The remaining import, ‘commons-lang3’ is used for other operations in the test project, like helping determine the OS on which tests are running. It is a library which contains a collection of helping methods, like processing of Strings, generating random Strings, easily working with Files, and so on.
1.2. Choose the OS to support
A decision you need to make is what OSs you want to be able to run your tests on. You don’t need to decide at the beginning, when you are creating your test framework, as you can add to the list of supported OSs as you progress in your testing. This is because the setup for a newly supported OS is not complicated and does not take too much time to accomplish.
When you decide on what OSs to run the tests on, think about who will run these tests: you or some colleagues of yours, or maybe they will be run on a remote machine, by a Jenkins runner.
It is important to know what these supported OSs for the tests are, because in the setup process you will need to use some files called ‘drivers’ (described in subchapter 1.4.) for allowing browser interactions. These are specific to each OS. What you don’t need to concern yourself with is which version of the OS you will use. For example, just think about whether Windows is supported, instead of considering whether Windows 10, 8, 7, XP and so on will be needed.
In these blog posts, for the sake of example, the supported OSs will be considered: Linux, Mac, Windows.
1.3. Choose the browsers to support
Based on the supported OSs, you can also choose which browser to support on each of them. Some browsers will of course work on only one OS (Internet Explorer), whereas some have cross-OS support (like Chrome or Firefox). This again is needed for knowing which browser drivers need downloading.
For each combination of OS + browser, you will need to download a corresponding binary file. That will be discussed in the next subchapter.
For the purpose of example, in these posts, the following browsers will be supported: for Windows: Chrome, Firefox; for Linux: Chrome, Firefox; for Mac: Chrome. The setup for each of these combinations of OS and browsers will be described further below.
1.4. Download the drivers for the supported browsers
1.4.1. What are the drivers
When you are interacting with a browser by means of a Selenium test, you are not directly giving commands to the browser. An intermediate step exists in your communication with the browser, which involves a file called a ‘driver’. The driver will receive the commands you want to send to the browser, and forward these to the browser. The response from the browser based on the commands you sent will also be received by the driver and forwarded back to your tests. Simply put, the communication between the test code and browser is: test → driver → browser (when issueing a browser interaction command) and browser → driver → test (for receiving the response of the interaction command).
The driver files are specific to each browser and the operating system they are running on. In order to run Selenium tests, you will need to download the driver files corresponding to the browser/operating system you are aiming to test on.
1.4.2. Where to download the drivers from
Each browser binary is maintained by different projects, as you can see on the official Selenium documentation page, the ‘Consumer browsers’ and ‘Specialised browsers’ sections: https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/. For the purpose of these blog posts, the Mozilla driver, called ‘geckodriver’, and the Chrome driver are downloaded and setup in the project. Their download locations are:
geckodriver: https://github.com/mozilla/geckodriver/releases
chromedriver: https://chromedriver.storage.googleapis.com/index.html
From each url you can download all the released versions of these drivers. However you need to take into account browser-driver compatibility: each driver version works with only specified browser versions. Ideally always use the latest driver version and latest browser version. In some cases, due to constant browser upgrades, you might encounter some strange errors in your tests, due to the fact that the latest browser you installed does not work with the driver you have in your project. If such a situation occurs, simply visit the driver download location and download the latest version. If you are already at the latest version, constantly go back to the download page, as the maintainers are surely working on a new version which will be compatible with your browser.
At each of these download locations, you will find the driver files corresponding to the Windows, Linux and Mac OSs. For some versions, you will also have the possibility to choose between driver files for 32 or 64 bits operating systems.
In order to have your tests run on any machine, the driver files should be stored in the test project (instead of a random location on your machine which then needs to also exist and contain these files on all machines where the tests will run). The suggested location for storing the driver files is a dedicated folder in the ‘src/test/resources’ location in your project. In the test project used across this post, the driver files are stored in the following location: src/test/resources/browserBinaries. This location will need to be specified in the browser initialization methods described in the following blog post.
For the examples in this post, the following drivers were downloaded: Chrome driver for Windows, Linux and Mac, and Mozilla geckodriver for the same OSs. Now, since the driver files for Linux and Mac have the same name for Chrome, the one for Mac will be renamed to ‘chromedriverMac’. Similarly, for geckodriver, the filename for the Mac driver will be changed to ‘geckodriverMac’. Therefore, the setup for this post contains, in the src/test/resources/browserBinaries folder, the following files: chromedriver.exe (for Windows), chromedriver (for Linux), chromedriverMac (for Mac), geckodriver.exe (for Windows), geckodriver (for Linux) and geckodriverMac (for Mac). The Windows and Linux versions of these files are those for the 64 bit operating systems.
In the following blog posts in this series you will see how to set up the browsers and how to open them, but also how to make sure you don’t hardcode them in tests.