Lately, the Microsoft Edge browser has been growing in popularity, recently unseating Firefox as the 3rd most popular web browser and approaching Safari in the number two spot. This means that any web application with a potentially wide user base should include MS Edge tests in its automated test suite. Setting this up to run automatically, particularly in *nix based CI servers, can be quite a hassle when compared to setting up Chrome and Firefox browser tests. In this article, I’ll show you the steps to get the Edge browser and web driver running in a Linux-like CI system.

Why should I run tests in multiple browsers

If you write web applications, you may only ever test them in the browser of your choice. For example, I use Chrome almost exclusively, and when I write new features for an application, I never really check and see if those features work the same in Firefox, Safari, Edge, or anything else.

For the most part, you can get away with this, but each browser is a little different and if you’re only testing through one browser, you only know how your web apps look and behave for people using that browser. There are subtle differences between browsers and I’ve received reports of browser-specific bugs from users before that I could’ve caught if I’d just verified my app through something other than Chrome.

Likewise, you should probably add some variety to your automated test suite and not rely solely on Chrome and Chromedriver for your web-based automated tests. I’m not saying you need to run every feature test in each major browser (though you certainly could) but any test that interacts with or verifies the status or behavior of:

• The UI
• Cookies
• Session data

should be tested in at least two popular browsers. These things have the most variability between different browsers, so it’s good practice to verify these attributes with multiple browsers and web drivers.

Now that we know why we want to test features with multiple browsers, let’s get to the main point of this article: running automated browser tests with Microsoft Edge and Edgedriver.

Edge-Specific Challenges

The reason an article like this is needed is because most CI pipelines run in Linux-like environments, and Microsoft Edge isn’t really “native” to this operating system. Additionally, many popular CI systems (like CircleCI, TravisCI, GitHub Actions) don’t have out-of-the-box support for Edge and Edgedriver like they do for Chrome and Chromedriver or Firefox and Geckodriver.

Therefore, we have to add some specific steps in our build files, which we’ll go over in the next section.

Add MS Edge and Edge Driver to Server

Our general strategy moving forward will be like so:

1. Install Microsoft GPG
2. Add MS Edge “dev” distro to sources list
3. Install the development version of MS Edge (the browser)
4. In the development version of Edgedriver (the Edge-specific web driver)
5. Make the driver accessible to the OS

Before I show you the script, there’s one more thing you need: the current Edgedriver development version. We’re going to save ourselves some work by only using the stable dev version of the Edge browser, which we can do by simply specifying “stable” in our script (which you’ll see in a moment) but there is no such easy way to get the latest stable Edgedriver. That’s why we need to go find the specific version.

To get the version number, go to this page and look at the version number under “Dev.” As of writing this, the number says 95.0.1020.5. We’ll use this number inside of a URL in our build script. Finally, the script will look like this:

curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
sudo install -o root -g root -m 644 microsoft.gpg /etc/apt/trusted.gpg.d/
sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/edge stable main" > /etc/apt/sources.list.d/microsoft-edge-dev.list'
sudo rm microsoft.gpg
sudo apt update
sudo apt install microsoft-edge-dev
wget https://msedgedriver.azureedge.net/95.0.1020.5/edgedriver_linux64.zip -P ~/
unzip ~/edgedriver_linux64.zip -d ~/
rm ~/edgedriver_linux64.zip
sudo mv -f ~/msedgedriver /usr/local/share/
sudo chmod 777 /usr/local/share/msedgedriver
sudo ln -s /usr/local/share/msedgedriver /usr/local/bin/msedgedriver

This script is currently a build step for a personal project of mine and is working fine in GitHub Actions. If you’re using a different CI, the exact syntax of how to lay out the different commands may be different, but the actual commands and their order are correct regardless of CI tool.

Notice in the wget command, we have the Edge driver version number in the URL and we’ve specified that we’re using the 64 bit Linux build.

Issues with Local vs Remote Driver

There is one issue I was running into when trying to run my tests in a remote CI server. I don’t remember the specifics of the issue, nor do I know if it will be the same in all Selenium ports (I use Python) but basically the issue is this: When you’re using the dev version of the browser and driver for edge, you have to tell Selenium you’re doing so or the tests will not find the driver.

My approach to fixing this issue is to set an environment variable in the CI script such as RUNNING_IN_CI=True or something similar and then check for that variable in the test. If it’s not there, that means I’m running tests locally and I don’t need to specify that I’m using the dev version. If that variable is present however, I need to set the following values (this is specific to LuluTest browser automation framework, but your implementation of Selenium will likely be similar):

options_hash = BrowserOptions({
    'driver_type': browser,
    'headless': True,
    'browser_binary_location': shutil.which('microsoft-edge-dev'),
    'webdriver_location': shutil.which('msedgedriver'),
    'operating_system': 'LINUX'
})

Here I’m using Python’s shutil library to find the path of Microsoft Edge and Edgedriver in the CI system, as well as some other housekeeping things. This is necessary if you’ve used a build script like mine above.

That should do it!

Join my OSS Browser Automation Project!

Thanks for reading this article, I hope it helped you. If you like browser automation and open-source software, consider checking out my OSS project LuluTest and adding some contributions. I’m looking for developers, testers, and writers alike! I’ve tried to make the project as beginner friendly and inclusive as possible so with #hacktoberfest 2021 coming up, maybe you can knock out some of your PRs with me.