It happens to the best of us - one minute you're happily coding away at your app, and then the next, for some reason, you now have to run your app's functional tests with Internet Explorer (IE)! Normally IE is not the preferred browser platform to support, but once in a while a client will come with valid business reasons that necessitate such support. This is the sort of unfamiliar situation my team found itself in a little while ago.
Our test suite setup was such that we were using Lettuce to do Gherkin-based BDD, with Splinter as a wrapper for Selenium and Phantomjs webdriver for headless functional tests. Our development environment was all Unix. Anything to do with IE then was not going to just be a plug and play solution. Or was it?
Local Setup with Sauce Labs
For our local IE functional tests with Sauce Labs, we used the selenium remote webdriver and Sauce Connect. Sauce Connect is a tunnelling application which enables the execution of tests in the Sauce Labs cloud environment from behind firewalls. Sauce Connect also makes it possible to run tests in the cloud when a public IP address for the local infrastructure is not available. Using Sauce Connect, it is therefore possible to test internally hosted applications (such as those running on localhost) without having to tinker with IP addresses or any additional network configurations.
These are the steps required to set this up:
Register for an account with Sauce Labs and take note of your username and api key
Download the appropriate version of Sauce Connect for your operating system and then follow these instructions to set up a tunnel to Sauce Labs
If you have followed the above steps, you should now be ready to run your functional tests on Sauce Labs’ cloud infrastructure. However, there is just one more thing - you need to edit your functional test suite setup to indicate that the tests should be run on SauceLabs.
With Lettuce, the browser to be used for running the functional tests would conventionally be specified in the terrain.py - an example being:
@before.all def open_browser(): world.browser = Browser("phantomjs")
To be able to run the functional tests on SauceLabs, the above terrain.py setup has to be changed to use the remote driver, and this has to be pointed to Sauce Labs. This can be accomplished by revising the terrain.py as shown below:
@before.all def open_browser(): remote_url = "http://SAUCE_USERNAME:SAUCE_ACCESS_KEY@ondemand.saucelabs.com:80/wd/hub" world.browser = Browser( driver_name="remote", url=remote_url, browser="internetexplorer", platform="Windows 7", version="8", name="Descriptive Name for Test" )
Note that you actually have to specify your Sauce Labs username and access key in the remote url. Also note that parameters such as the platform and version should be customised as per your requirements. Now on invoking the functional tests, they will run on Sauce Labs. (Yes, that's it!) The tests can be monitored as they run in the browser by logging in to the created Sauce Labs account, navigating to saucelabs.com/tests and then selecting the running test.
Using Sauce Labs with a Continuous Integration (CI) Service
Running your tests only locally will not get you much mileage, especially if you are working with a sizeable team. Using a Continuous Integration service is therefore essential. Fortunately, Sauce Labs has first class support for a number of Continuous Integration services including Jenkins, Bamboo, Travis and TeamCity. The preceding links should contain sufficient information to integrate Sauce Labs with each of those CI services. In our case however, we had already set up Snap-CI as our CI service of choice. Snap-CI currently does not provide such integration with Sauce Labs. We therefore made the following adjustments to include Sauce Labs in our build pipeline:
As part of our functional test stage on Snap-CI, it was necessary to set up a tunnel to Sauce Labs using Sauce Connect, otherwise the browsers at Sauce Labs would not be able to run against our application instance in the Snap-CI Build Pipeline. We came across this gist which we altered to suit the requirements of our Snap Build. The gist takes care of downloading, starting and waiting for Sauce Connect to establish a tunnel before the functional tests are actually run
The terrain.py setup remained largely unchanged, except for the use of environment variables rather than the explicit declaration of the Sauce Username and API Access Key. Given that Snap-CI exports a number of additional environment variables during each build, it was also possible to annotate the test descriptions with these variables. Using annotations such as the pipeline counter and the git commit subsequently made it easier to identify the appropriate test in the Sauce Labs test dashboard.
Are you in a position where you need to run IE tests without getting your hands dirty? If so, maybe Sauce Labs can save your time as well. If on the other hand you are more interested in evaluating some of the other options out there, then this guide is a good place to start.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.