Repost: Testing in a Real Browser with Sauce Labs + Travis CI

Posted by Bill McGee in Continuous Integration

This post comes from our friend Sam Saccone, who wrote a nice how-to on using Sauce Connect and Travis CI. Check out the original post on his blog.

I recently found myself implementing a basic set of JavaScript integration tests on an open source project. I quickly came to the realization that there is a serious lack of good documentation on how to get a basic browser test running on a Travis CI using Sauce Labs and Sauce Connect.

After stumbling across the barren desert of outdated doc pages, incorrect stackoverflow answers, and ancient google group posting, I present to you the spoils of my quest to the underbelly of the web.

Let's approach this in the context of a real problem: Testing javascript in a real web browser. (view the complete project here)


(view the full diff) To get going we are going to setup to run on our repo.

Setting up our repo to work with travis

Once travis is enabled we will want to setup a basic .travis.yml file to run a basic test on our repo.

[code language="ruby"]language: node_js node_js: - "0.12[/code]

We are telling it to use node_js and specifying the version of node. By default node projects will run npm install and npm test so everything should be good to go. And we will see our basic test run

Creating our first browser test.

sam browser test

(commit diff)

To take advantage of Sauce Lab and Sauce Connect we are going to need to use selenium webdriver. In case you are not familiar with selenium, it allows you to remotely control a web browser through code (pretty awesome stuff).

The documentation for it is a bit hard to find but I will link it here so you do not have to go hunting

We will want to install selenium and setup out basic tests

Instead of going over the entire diff lets look at a few critical pieces of the code.

[code language="ruby"]var assert = require("assert"); var webdriver = require("selenium-webdriver");

describe("testing javascript in the browser", function() { beforeEach(function() { this.browser = new webdriver.Builder() .withCapabilities({ browserName: "chrome" }).build();

return this.browser.get("http://localhost:8000/page/index.html");


afterEach(function() { return this.browser.quit(); });

it("should handle clicking on a headline", function(done) { var headline = this.browser.findElement(webdriver.By.css('h1'));;

headline.getText().then(function(txt) { assert.equal(txt, "awesome"); done(); });

}); });[/code]

At a high level we are setting up selenium to launch a chrome instance, visiting the page we want to test, clicking on an element, and then asserting that the clicked element's text has changed to an expected value.

There is a bit of async complexity going on that mocha and selenium for the most part abstract for us, so no need to fret about that for now.

If you noticed we are visiting http://localhost:8000, that means that we need to boot up a server to serve our content. Travis makes this easy enough via a before_script task. In the task we will just start a python simple server and give it a few seconds to boot. The ampersand at the end of the python line tells travis to run the process in the background instead of blocking the execution thread, allowing us to run tasks at the same time.

[code language="ruby"]language: node_js before_script:

  • python -m SimpleHTTPServer &
  • sleep 2 node_js:
    • "0.12"[/code]

Believe it or not that is all we need to run our tests in a real browser (or at least it seems to satisfy the requirements to run things locally).

And in Comes Sauce Labs

(view the full diff) When we push our work from before, we are rudely awoken by the unfortunate fact that nothing is working on travis.

sam sauce labs

This is where we will lean on Sauce. Sauce Labs provides its services for free for Open Source projects. We can get our access keys via and just add the encrypted keys to our travis.yml file, these keys will allow us to connect to Sauce's VM cluster to run our tests against.

sam sauce labs 2

From here we just need to enable the sauce_connect addon for travis, again only a minor change to the travis.yml file is needed.

sam travis

The next step is to tweak our selenium browser build step to use sauce labs VMs instead of the local machines.

[code language="ruby"] beforeEach(function() { if (process.env.SAUCE_USERNAME != undefined) { this.browser = new webdriver.Builder() .usingServer('http://'+ process.env.SAUCE_USERNAME+':'+process.env.SAUCE_ACCESS_KEY+'') .withCapabilities({ 'tunnel-identifier': process.env.TRAVIS_JOB_NUMBER, build: process.env.TRAVIS_BUILD_NUMBER, username: process.env.SAUCE_USERNAME, accessKey: process.env.SAUCE_ACCESS_KEY, browserName: "chrome" }).build(); } else { this.browser = new webdriver.Builder() .withCapabilities({ browserName: "chrome" }).build(); }

return this.browser.get("http://localhost:8000/page/index.html");


Our beforeEach step gets a tiny bit more complex. We first detect if there is a sauce environment variable and if so we setup the browser with the required parameters for it to connect to Sauce's infrastructure. After that setup is done, we can be blind to the changes that we made, since we will not have to worry about it again.

Once we push our changes we can see everything works like charm!

sam sauce 3

We even get an awesome playback video from sauce to help us debug if there were any problems Sauce Test Playback

Hopefully this helps to codify the path to adding integration tests on your javascript projects. If you still have questions please reach out via a github issue or on twitter. Sam Saccone @samccone

Discuss: Repost: Testing in a Real Browser with Sauce Labs + Travis CI

Free Trial

Get access to a free 14-day trial version, or contact Sales for more information.