Installing GeckoDriver on macOS

Overview of naming conventions

  • GeckoDriver is the library you need to download to be able to use Selenium WebDriver with Firefox. These are the Selenium Bindings.
  • Marionette is the protocol which Firefox uses to communicate with GeckoDriver. Installed by default with Firefox.
  • FirefoxDriver is the former name of GeckoDriver.

Ways to install GeckoDriver:

  1. The easiest way to install GeckoDriver is to use a package manager like brew or npm such as npm install geckodriver. This method requires you some package manager installed but you probably should anyways.
  2. Run Firefox and GeckoDriver in a container using Docker. Simply download the combined container, start it and point your code at the right address. I’ve written about how to do this using Chrome, should be very similar to do Firefox.
  3. Specify it in your Selenium setup code. If you go this route, you can include ChromeDriver as well.
  4. Download the driver and add its location to your System PATH. These instructions are for Chrome but should work for GeckoDriver as well.

Once this is done, it should work like nothing has changed. The big advantage is you’ll now be able to use Firefox browsers newer than 46!

Selecting a few Platform Configuration Tests

I’ve been developing a GUI acceptance test suite to increase the speed of specific types of feedback about our software releases. In addition to my local environment I’ve been using Sauce Labs to extend our platform coverage (mostly by browsers and operating) and to speed up our tests by running more tests in parallel.

This pretty similar to what I consider traditional configuration testing – making sure your software can run in various configurations with variables such as RAM, OS, Video card, etc. Except on the web the variables are a little different and I am more concerned with browser differences than say operating system differences. Nevertheless, with over 700 browsers and OS platforms at Sauce Labs I still need to decide what configurations I start with and what configurations I add over time in the hope of finding failures.

Data

I figured the best place to start was with our current users and since the only “hard” data we had comes from Google Analytics, I pulled up the details of two variables (OS and Browser). Using TestingConference.org as a replacement for my company’s data, our most commonly used platform configurations include:

  • Browsers:
    • Chrome 47 & 48,
    • Firefox 43 & 44,
    • Safari 8 & 9, and
    • Internet Explorer 10 & 11
  • Operating Systems:
    • Windows 7,
    • Windows 8.1,
    • Windows 10,
    • Mac OSX 10.11 and
    • Mac OSX 10.10

Excluding a few constraints like IE only runs on Windows and Safari only runs on Mac, testing browsers and operating systems in combination could potentially yield up to 40 different configurations (8 browsers x 5 operating systems). Also, we designed our application to be responsive and at some point we probably want to test for a few browser resolutions. If we’ve got 40 initial configurations and 3 different browser resolutions that could potentially yield up to 64,000 different configurations. Realistically even for an automated suite and with one to two functional tests, that’s too many tests to run.

Reduce the number of tests

We can start with adding in those constraints I mentioned above and then focuses on just the variables we want to ensure we have coverage of. To get a better picture of the number of possible configuration tests I used ACTS (Automated Combinatorial Testing for Software) tool and based my constraints on what Sauce Labs has available today for configurations. After I added OS and Browsers it looked something like this:

ACTS Window

If I wanted every browser and operating system in combination to be covered (all-pairs) then according to ACTS there aren’t 40 different configurations, just 24 configuration options. That’s more manageable but still too many to start with. If I focus on my original concerns of covering just the browsers, I get back to a more manageable set of configuration options:

Test OS Browser
1 Windows8.1 Chrome47
2 Windows10 Chrome48
3 OSX10.11 Firefox43
4 Windows7 Firefox44
5 OSX10.10 Safari8
6 OSX10.11 Safari9
7 Windows10 IE10
8 Windows7 IE11

8 configuration options are way more manageable and less time consuming than 24 options, considering each one of those configurations will each run a few dozen functional tests as well.

A Good Start

Selecting the configurations is probably the easiest part of configuration testing (and the only thing I’ve shown) but I’ve found its worth thinking through. (The harder part is designing the automated acceptance tests to produce useful failures.) Using ACTS at this point may seem like overkill when we could have just selected the browsers from the beginning but it didn’t take much time and should make it easier in the future when we want to add more variables or change the values of our existing variables.

Installing ChromeDriver on macOS

The ChromeDriver getting started guide isn’t super helpful if you are unfamiliar with including the ChromeDriver location in your PATH environment variable. (The PATH variable helps Chrome find the downloaded ChromeDriver exe). Also it’s a lot of work for something so common. Never fear, here is a better way:

Installing on macOS:

Listed in order of easiest to hardest install, these are the best ways to install ChromeDriver on a Mac:

  • The easiest way to install ChromeDriver is to use your package manager such as brew or npm to install the driver.
    • In your terminal window with the Homebrew package manager:
      • Install ChromeDriver with brew cask install chromedriver
      • Confirm it was installed using chromedriver --version and seeing it returns a version. If it errors it wasn’t installed
    • Other package managers like npm have similar commands npm install chromedriver
  • Run Chrome & ChromeDriver in a container using Docker. Simply download the combined container, start it and point your code at the right address.
  • Specify it in your Selenium setup code and check it into source control like any other configuration detail. If you go this route, you can include additional drivers like GeckoDriver (aka Firefox) as well.
  • Download the driver and add its location to your System PATH.

Which methods have you found the easiest or most success with? Which methods didn’t work for you? Please leave a comment below. 

Additional Resources

Oh and if this article worked for you please consider sharing it or buying me coffee to say thanks.

Installing Ruby and Watir on Windows 7

I recently started playing around with Web Application Testing in Ruby or Watir for short. As is recommended, I downloaded the Homebrewer’s Guide to Watir by Zeljko Filipin and started trying to install the latest versions of the RubyInstaller for Windows (currently 2.0.0) when I ran into a few problems. (I like the idea of using Leanpub to create and modify install documents for open source applications.)

I installed Ruby and Watir on a Windows 7 64 bit machine using the 32 bit versions and everything seems to work fine so far. Here’s how I installed everything using the RubyInstaller and instructions from the above guide (note: some of these instructions will be a duplicate of the guide):

Ruby Installation

  1. Open a command prompt (Run and type cmd) and type ruby -v to see if you have Ruby installed (if you don’t it will say the command isn’t recognized) and the version number.
  2. I have Windows 7 64 bit but I used the 32 bit installers from RubyInstaller Downloads including:
    1. Ruby 2.0.0-p247
    2. DevKit-mingw64-32-4.7.2
  3. Run the Ruby installer and on the optional tasks page select the below items before completing:
    1. Add Ruby executables to your PATH
    2. Associate .rb and .rbw files with this Ruby installation
  4. Open a new command prompt and type ruby -v to see if Ruby installed and the version number.
  5. (Optional) Once installed you can update the RubyGems distributed with the installer by typing gem update --system and watching for the “RubyGems system software updated” to know when its complete.
  6. Move on to the DevKit installation.

DevKit Installation

  1. Run the DevKit installer but change the extraction folder to C:devkit
  2. Open a command prompt (Run and type cmd) and change the folder to C:devkit (use the command cd c:devkit).
  3. Run the command ruby dk.rb init. If this step is successful you’ll see a response like “[INFO] found RubyInstaller v2.0.0 at C:/Ruby200”.
  4. Run the command ruby dk.rb install. If this step is successful you’ll see a response like [INFO] Installing C:/Ruby200/lib/ruby/site_ruby/2.0.0/
    rubygems/defaults/operating_system.rb
    and [INFO] Installing C:/Ruby200/lib/ruby/site_ruby/devkit.rb
  5. Move on to Watir installation.

Watir Installation


This is where I ran into problems with the 2.0.0 version of Watir. Something about the mini_magick version erroring out. To prevent this problem we do:

  1. Run the command (still from the C:devkit command window) gem install mini_magick -v 3.5.0 which works around the version problem. You should get a response like “2 gems installed”
  2. Then run the command gem install watir --no-ri --no-rdoc to install the rest of Watir. You should get a response like “Successfully installed watir-4.0.2-x86-mingw32 and 23 gems installed”.

Check the installation

In the same command window type (after each line of code submit the commands)
  1. irb
  2. require "watir"
  3. browser = Watir::Browser.new
  4. browser.goto "google.com"

If all is setup correctly you should get your default browser to open a new window and then browse to Google. Good luck.

Note: These steps weren’t meant to replace the Homebrewer’s Guide to Watir by Zeljko Filipin instructions but to improve them for the 2.0.0 release. For everything else please refer to the guide.