Selenium Bootcamp is a series of articles prepared by Selenium guru Dave Haeffner for Sauce Labs. Dave also authors the Elemental Selenium website, which includes tips for using Selenium, and where you can sign up for his weekly email on the topic of Selenium testing.
Now that we have some tests and page objects, we'll want to start thinking about how to structure our test code to be more flexible. That way it can scale to meet our needs.
Global Setup & Teardown
We'll start by pulling the Selenium setup and teardown out of our tests and into a central location.
To do that, we'll want to create a base test. So let's create a new file called
Base.java in the
│ └── test
│ └── java
│ ├── pageobjects
│ │ ├── DynamicLoading.java
│ │ └── Login.java
│ └── tests
│ ├── Base.java
│ ├── TestDynamicLoading.java
│ └── TestLogin.java
And here are the contents of the file.
After importing a few necessary classes we specify the
Base class and wire up some methods that will take care of setting up and tearing down Selenium before and after every test.
It's worth noting that we could have used methods with
@After annotations just like before. But if we did that we'd be giving up the ability to use these annotations in our tests (which we'll want to use for page object instantiation).
To preserve this functionality we're using JUnit's
ExternalResource Rule. This rule has
after methods that execute prior to methods annotated with
@After. For more info on JUnit's Rules, read this. Now let's update our tests to establish inheritance with this base test class, remove the Selenium setup/teardown actions, and remove the unnecessary import statements. When we're done our test files should look like this:
Running Tests On Any Browser
If you've ever needed to test features in an older browser like Internet Explorer 8 then odds are you ran a virtual machine (VM) on your computer with a "legit" version of Windows XP.
Handy, but what happens when you need to check things on multiple versions of IE? Now you're looking at multiple VMs. And what about when you need to scale and cover other browser and Operating System (OS) combinations? Now you're looking at provisioning, running, and maintaining your own set of machines and standing up something like Selenium Grid to coordinate tests across them.
Rather than take on the overhead of a test infrastructure you can easily outsource this to a third-party cloud provider like Sauce Labs.
With Sauce Labs we need to provide specifics about what we want in our test environment, our credentials, and configure Selenium a little bit differently than we have been. Let's start by creating a file for these various configuration values.
Let's create a file called
Config.java in the tests package.
In it we'll create an interface and specify field variables for the different configuration values we need.
host enables us to specify whether our tests run locally or on Sauce Labs. If we don't specify a value at runtime, then the tests will execute locally.
platform we can specify which browser and operating system combination we want our tests to run on. You can see a full list of Sauce's available platform options here. They also have a handy configuration generator (which will tell you what values to plug into your test) here. We've made so if no values are provided at run time, they will default to
33 running on
sauceUser is your Sauce username, and
sauceKey is your Sauce Access Key (which can be found on your account dashboard). An alternative to hard-coding your credentials is to store them in environment variables and retrieve them.
Do whichever you're more comfortable and familiar with.
Now we can update our base test class to work with Selenium Remote (which is how we'll be able to connect to Sauce Labs).
before method we've added a new conditional flow (e.g.,
else if) to check the
We start by checking to see if it's set to
"saucelabs". If it is we create a
DesiredCapabilitiesobject, populate it (with
platform values), and connect to Sauce Labs using Selenium Remote (passing in the
DesiredCapabilities object). This will return a Selenium WebDriver object that we can use just like when running our tests locally.
host variable is set to
"localhost" then our tests will run locally just like before.
If we save everything and run our tests in Sauce Labs (e.g.,
mvn clean test -Dhost=saucelabs) then on the account dashboard we'll see our tests running in Firefox 33 on Windows XP.
And if we wanted to run our tests on different browser and operating system combinations, here are what some of the commands would look like:
Notice the properties with quotations (e.g.,
"internet explorer" and
"OS X 10.10"). When dealing with more than one word in a runtime property we need to make sure to surround them in double-quotes (or else our test code won't compile).
That wraps up The Selenium Bootcamp.
There's a whole lot more to think about when it comes to using Selenium successfully. If you’re interested in learning what it takes and how to do it, then grab a copy of The Selenium Guidebook today!