- Getting Started with Selenium for Automated Website Testing
- Getting Started with Appium for Mobile Native Application Testing
- Selenium Bootcamp by Dave Haeffner
- Appium Bootcamp by Dave Haeffner and Matthew Edwards
Appium Bootcamp is a series of articles prepared by Selenium guru Dave Haeffner, and leading Appium contributor Matthew Edwards, 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. He is also the author of the Selenium Guidebook.
Now that we have our tests written, refactored, and running locally it's time to make them simple to launch by wrapping them with a command-line executor. After that, we'll be able to easily add in the ability to run them in the cloud.
appium_lib comes pre-wired with the ability to run our tests in Sauce Labs, but we're still going to need two additional libraries to accomplish everything;
rake for command-line execution, and
sauce_whisk for some additional tasks not covered by
Let's add these to our
Gemfile and run
Simple Rake Tasks
Now that we have our requisite libraries let's create a new file in the project root called
Rakefile and add tasks to launch our tests.
Notice that the syntax in this file reads a lot like Ruby -- that's because it is (along with some Rake specific syntax). For a primer on Rake, read this.
In this file we've created two tasks. One to run our iOS tests, and another for the Android tests. Each task changes directories into the correct device folder (e.g.,
Dir.chdir) and then launches the tests (e.g.,
If we save this file and run
rake -T from the command-line, we will see these tasks listed along with their descriptions.
If we run either of these tasks (e.g.,
rake android or
rake ios), they will execute the tests locally for each of the devices.
Running Your Tests In Sauce
As I mentioned before,
appium_lib comes with the ability to run Appium tests in Sauce Labs. We just need to specify a Sauce account username and access key. To obtain an access key, you first need to have an account. After that, log into the account and go to the bottom left of your dashboard; your access key will be listed there.
We'll also need to make our apps available to Sauce. This can be accomplished by either uploading the app to Sauce, or, making the app available from a publicly available URL. The prior approach is easy enough to accomplish with the help of
Let's go ahead and update our
spec_helper.rb to add in this new upload capability (along with a couple of other bits).
Near the top of the file we pull in
sauce_whisk. We then add in a couple of helper methods (
using_sauce checks to see if Sauce credentials have been set properly.
upload_app uploads the application from local disk and then updates the capabilities to reference the path to the app on Sauce's storage.
We put these to use in
setup_driver by wrapping them in a conditional to see if we are using Sauce. If so, we upload the app. We're also removing the
avd capability since it will cause issues with our Sauce run if we keep it in.
Next we'll need to update our
appium.txt files so they'll play nice with Sauce.
In order to work with Sauce we need to specify the
appium-version and the
platformVersion. Everything else stays the same. You can see a full list of Sauce's supported platforms and configuration options here.
Now let's update our Rake tasks to be cloud aware. That way we can specify at run time whether to run things locally or in Sauce.
We've updated our Rake tasks so they can take an argument for the location. We then use this argument value and pass it to
location_helper looks at the location value -- if it is not set to
'sauce' then the Sauce credentials get set to
nil. This helps us ensure that we really do want to run our tests on Sauce (e.g., we have to specify both the Sauce credentials AND the location).
Now we can launch our tests locally just like before (e.g.,
rake ios) or in Sauce by specifying it as a location (e.g.,
But in order for the tests to fire in Sauce Labs, we need to specify our credentials somehow. We've opted to keep them out of our
Rakefile (and our test code) so that we can maintain future flexibility by not having them hard-coded; which is also more secure since we won't be committing them to our repository.
Specifying Sauce Credentials
There are a few ways we can go about specifying our credentials.
Specify them at run-time
Export the values into the current command-line session
Set the values in your bash profile (recommended)
Making Your Sauce Runs Descriptive
It's great that our tests are now running in Sauce. But it's tough to sift through the test results since the name and test status are nondescript and all the same. Let's fix that.
Fortunately, we can dynamically set the Sauce Labs job name and test status in our test code. We just need to provide this information before and after our test runs. To do that we'll need to update the RSpec configuration in
before(:each) we update the
name attribute of our capabilities (e.g.,
caps[:name]) with the name of the test. We get this name by tapping into the test's metadata (e.g.,
example.metadata[:full_description]). And since we only want this to run if we're using Sauce we wrap it in a conditional.
after(:each) we leverage
sauce_whisk to set the job status based on the test result, which we get by checking to see if any exceptions were raised. Again, we only want this to run if we're using Sauce, so we wrap it in a conditional too.
Now if we run our tests in Sauce we will see them execute with the correct name and job status.
Now that we have local and cloud execution covered, it's time to automate our test runs by plugging them into a Continuous Integration (CI) server.