The Problem
It’s straightforward to get your tests running locally against Firefox. But when you want to run them against a different browser like Chrome, you quickly run into configuration overhead that can seem overly complex and lacking in code examples for getting started.A Solution
With the introduction of WebDriver (circa Selenium 2) a lot of benefits were realized (e.g. more effective & faster browser execution, no more single host origin issues, etc). But with it came some architectural & configuration differences that may not be widely known. Namely — browser drivers. WebDriver works with each of the major browsers through a browser driver which is (ideally) maintained by the browser manufacturer. It is an executable file (consider it a thin layer or a shim) that acts as a bridge between Selenium and the browser. Let’s step through an example using ChromeDriver.An Example
Before starting, we’ll need to download the latest ChromeDriver binary executable from here. Once we have it we’ll need to tell Selenium where it is. And there are three ways to do this:- Add it to your System PATH
- Specify it your test setup
- Launch ChromeDriver and connect to it via Selenium Remote
org.junit.After, etc.), driving the browser with Selenium (e.g., org.openqa.selenium.WebDriver, etc.), and matchers for our assertions (e.g., org.hamcrest.CoreMatchers, etc.)) and start our class with some setup and teardown methods.
// filename: ChromeDriverExample.java
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.assertThat;
public class ChromeDriverExample {
WebDriver driver;
@Before
public void setUp() throws Exception {
System.setProperty("webdriver.chrome.driver",
System.getProperty("user.dir") + "/../../vendor/chrome-driver-2.15/chromedriver_mac32");
driver = new ChromeDriver();
}
@After
public void tearDown() throws Exception {
driver.quit();
}
// ...
setUp we are telling Selenium where the ChromeDriver exectuable is with setProperty("webdriver.chrome.driver"before creating an instance of the browser. And by using System.getProperty("user.dir") we are able to reference the ChromeDriver binary within our project. Now we’re ready to add a test.// filename: ChromeDriverExample.java
// ...
@Test
public void chromeDriverTest() {
driver.get("http://the-internet.herokuapp.com/");
assertThat(driver.getTitle(), is(equalTo("The Internet")));
}
}
mvn clean test) it will launch an instance of Chrome, visit the homepage of the-internet, and assert that the page title loaded.Another Example
Alternatively, we can launch ChromeDriver from the command-line…
> ./chromedriver
Starting ChromeDriver 2.18.343837 (52eb4041461e46a6b73308ebb19e85787ced4281) on port 9515
Only local connections are allowed.
// filename: ChromeDriverExample.java
// ...
@Before
public void setUp() throws Exception {
driver = new RemoteWebDriver(new URL("http://localhost:9515"), DesiredCapabilities.chrome());
}
// ...
Expected Behavior
When you save this file and run it (e.g.,mvn clean test from the command-line) here is what will happen. Example 1- ChromeDriver starts
- Chrome opens
- Test runs
- Chrome closes
- ChromeDriver stops
- ChromeDriver starts (via command-line execution)
- Chrome opens
- Test runs
- Chrome closes
- ChromeDriver continues to run until stopped
Outro
Hopefully this tip has helped you get a better handle on how WebDriver works with various browsers and saved you some time in your configuration setup. But keep in mind that no two browser drivers are alike, so be sure to check out the documentation for the browser you care about to find out it’s specific requirements: Happy Testing!Sign Up To Our Upcoming Webinar – iOS Test Automation at Continuous Delivery Pipeline (5 Seats Left!) Sign up http://bit.ly/CodeFitnessWebinar
Important: even if you can’t make it to the live session, register to get the recording, so you can access it when you need it!
JOIN US on Thu, Apr 19, 2018 12:00 PM – 1:00 PM PDT
Join Igor Dorovskikh (Test Automation Lead at Tinder ) and Boris Gurtovoy (iOS Developer at Tinder) to learn:
- What is XCUITests
- Live vs Stubbed tests
- How to make functional tests ready for Continuous Integration
- Continuous Integration vs Continuous Delivery in iOS context
- How to leverage Headspin device farm to measure and monitor mobile app performance across global regions and mobile devices
