Mark Needham

Another thing we’ve been doing with WebDriver is having it run with the FirefoxDriver while redirecting the display output into the Xvfb framebuffer so that we can run it on our continuous integration agents which don’t have a display attached.

The first thing we needed to do was set the environment property ‘webdriver.firefox.bin’ to our own script which would point the display to Xvfb before starting Firefox:

import java.lang.System._
lazy val firefoxDriver: FirefoxDriver = {
  setProperty("webdriver.firefox.bin", "/our/awesome/starting-firefox.sh")
  new FirefoxDriver()
}

Our first version of the script looked like this:

/our/awesome/starting-firefox.sh

#!/bin/bash
 
rm -f ~/.mozilla/firefox/*/.parentlock
rm -rf /var/go/.mozilla
 
 
XVFB=`which xVfb`
if [ "$?" -eq 1 ];
then
    echo "Xvfb not found."
    exit 1
fi
 
$XVFB :99 -ac &
 
 
BROWSER=`which firefox`
if [ "$?" -eq 1 ];
then
    echo "Firefox not found."
    exit 1
fi
 
export DISPLAY=:99
$BROWSER &

The mistake we made here was that we started Xvfb in the background which meant that sometimes it hadn’t actually started by the time Firefox tried to connect to the display and we ended up with this error message:

No Protocol specified
Error cannot open display :99

We really wanted to keep Xvfb running regardless of whether the Firefox instances being used by WebDriver were alive or not so we moved the starting of Xvfb out into a separate script which we run as one of the earlier steps in the build.

We also struggled to get the FirefoxDriver to kill itself after each test as calling ‘close’ or ‘quit’ on the driver didn’t seem to kill off the process.

We eventually resorted to putting a ‘pkill firefox’ statement at the start of our firefox starting script:

/our/awesome/starting-firefox.sh

#!/bin/bash
 
rm -f ~/.mozilla/firefox/*/.parentlock
rm -rf /var/go/.mozilla
 
pkill firefox
 
BROWSER=`which firefox`
if [ "$?" -eq 1 ];
then
    echo "Firefox not found."
    exit 1
fi
 
export DISPLAY=:99
$BROWSER &

It’s a bit hacky but it does the job more deterministically than anything else we’ve tried previously.

As I mentioned in an earlier post about removing manual test scenarios we’ve been trying to automate some parts of our application where a user action leads to a jQuery ColorBox powered overlay appearing.

With this type of feature there tends to be some sort of animation which accompanies the overlay so we have to wait for an element inside the overlay to become visible on the screen before trying to do any assertions on the overlay.

We have a simple method to do that:

def iWaitUntil(waitingFor: => Boolean) {
  for (i <- 1 to 5) {
    if(waitingFor) {
      return
    }
   Thread.sleep(200)
  }
}

It can then be called like this in our tests:

def driver: WebDriver = new FirefoxDriver()
 
iWaitUntil(driver.findElements(By.cssSelector(".i-am .inside-the-colorbox h3")).nonEmpty)
driver.findElement(By.cssSelector(".i-am .inside-the-colorbox h3")).getText should equal("Awesome Title")

Annoyingly what we noticed was that this wasn’t enough and although the h3 element was coming back as being visible it was then failing the following assertion because ‘getText’ was returning nothing despite the fact that it clearly had text inside it!

Uday came up with the neat idea of adding an additional wait clause which would wait until the text was non empty so we now have something like this…

def driver: WebDriver = new FirefoxDriver()
 
iWaitUntil(driver.findElements(By.cssSelector(".i-am .inside-the-colorbox h3")).nonEmpty)
driver.findElement(By.cssSelector(".i-am .inside-the-colorbox h3")).getText should equal("Awesome Title")
iWaitUntil(driver.findElement(By.cssSelector(".i-am .inside-the-colorbox h3")).getText != "")

…which seems to do the job nicely.

An alternative approach would have been to disable the animation of jQuery ColorBox just for our tests but the approach we took was a much quicker win at the time.

We did realise later on that we didn’t need to write our own wait method since WebDriver has one built into the API but I guess they both do similar things so it’s not such a big problem.

We’re using WebDriver on my project to automate our functional tests and as a result are using the Page Object pattern to encapsulate each page of the application in our tests.

We’ve been trying to work out how to effectively reuse code since some of the pages have parts of them which work exactly the same as another page.

For example we had a test similar to this…

class FooPageTests extends Spec with ShouldMatchers with FooPageSteps {
  it("is my dummy test") {
    ...
    then(iShouldNotSeeAnyCommonLinks())
  }
}

…where FooPageSteps extends CommonSteps which contains the common assertions:

trait FooPageSteps extends CommonSteps {
  override val page = new FooPage(driver)
}

trait CommonSteps {
  val page : FooPage
  val driver: HtmlUnitDriver
 
  def iShouldNotSeeAnyCommonLinks() {
    page.allCommonLinks.isEmpty should equal(true)
  }
}

FooPage looks like this:

class FooPage(override val driver:WebDriver) extends Page(driver) with CommonSection {
 
}
 
abstract class Page(val driver: WebDriver) {
  def title(): String = driver.getTitle;
}
 
trait CommonSection {
  val driver:WebDriver
  def allCommonLinks:Seq[String] = driver.findElements(By.cssSelector(".common-links li")).map(_.getText)
}

We wanted to reuse CommonSteps for another page like so:

trait BarPageSteps extends CommonSteps {
  override val page = new BarPage(driver)
}
 
class BarPage(override val driver:WebDriver) extends Page(driver) with CommonSection {
 
}

But that means that we need to change the type of page in CommonSteps to make it a bit more generic so it will work for BarPageSteps too.

Making it of type Page is not enough since we still need to be able to call the allCommonLinks which is mixed into FooPage by CommonSection.

We therefore end up with the following:

trait CommonSteps {
  val page : Page with CommonSection
  val driver: HtmlUnitDriver
 
  def iShouldNotSeeAnyCommonLinks() {
    page.allCommonLinks.isEmpty should equal(true)
  }
}

We’re able to mix in CommonSection just for this instance of Page which works pretty well for allowing us to achieve code reuse in this case!