Keep up with Sauce Events with Our New Lanyrd Team Page

June 18th, 2013 by lauren nguyen

lanyrd-logoSo, we go to a lot of events. Whether they’re meetups, conferences, happy hours, or hackathons, we love getting out of the office and meeting the dev community in person.

To make it easy to see which conferences and events different team members will be at, we’ve got an awesome new Lanyrd team page. Lanyrd is an great conference directory, and we’re excited to have a new team page on it, so you can see what events are coming up, see which team members are going, and even review our old talks and sessions. Hope you see you at an event sometime soon!

Share

Coming to OSBridge? Come Say Hi!

June 11th, 2013 by lauren nguyen

osbridgeIf you’re going to Portland next week for OSBridge, which is celebrating its 5th year anniversary, be on the lookout for Saucers on the premises! Silas, Sebas, Adam, Lauren, and Mathieu will be at the conference; just look for the people in the Sauce Labs shirts. We’re really excited to convene and connect in person with our peers in the OSS community.

Sebas will also be giving a talk titled “Let the Internet Work for YouThursday 6/20 at 2:30 in room B304, so make sure to check it out!

Share

Learn Selenium in Industrial Logic’s Course “Driving Selenium Safely”

June 10th, 2013 by lauren nguyen

Driving-Selenium-Safely-2501Looking to get a jump start on learning Selenium to automate your testing? Want to get hands-on training on testing in the cloud? Our friends at Industrial Logic, who create awesome, informative online classes and in-person workshops, have been hard at work developing a course on Selenium 2, and they’re holding a 2 day open enrollment workshop in Silicon Valley. Join Patrick Wilson-Welsh at Hacker Dojo in Mountain View, CA July 9-10th for their “Driving Selenium Safely” workshop.

You’ll learn how and when to use Selenium to automate your testing, to using Selenium to test rich internet apps, to how to run your tests in the cloud with Sauce. It’s an introductory course, but you’ll learn a ton of useful skills. What’s really great about this course is that it focuses on using Selenium in real life, and tries to address some of the challenges and pitfalls you might experience as you’re automating your own web apps. Each participant will also receive a perpetual license to Industrial Logic’s online album for the course, so you can review the material whenever you like. Check out this page for more details and to buy tickets. There’s a discount for groups!

Driving Selenium Safely
with Industrial Logic
Hacker Dojo, Mountain View, CA
July 9-10

Share

Selenium Conference 2013 Is Here!

June 7th, 2013 by lauren nguyen

seconfSelenium Conference is nearly upon us! SeConf is always one of our most important events of the year, because Selenium is a huge part of what we do here at Sauce. We’re excited to be sponsoring the conference this year, and we’ll be out in force at the event; so come say hi! We’ll also be doing a workshop on Appium Monday 6/10 from 9AM-12PM, and a workshop 6/10 from 1PM-4PM on rewriting the official Selenium docs, so check it out if you want to learn more about mobile app automation. See you there!

Share

Job IDs; What Are They Good for?

June 6th, 2013 by Dylan

What’s a Job ID?

You’ve might have come across the term “job ID”, “test ID” or “session ID” in our documentation. These refer to the unique ID which each Sauce Labs job has. You can find it in the URL of a jobs page, and in the test summary pane.

<Insert Joke Here>

Job IDs in the wild

This value is also used by any remote Selenium session as the session ID. When you use the selenium-webdriver or sauce gems to drive a job, every action you take until you call #quit is performed for the same session.

So?

So once you have this session ID, you’ve got a unique reference to a job and all its resources. This means you can use it to:

  • Set job metadata like build-id, using our REST API
  • Download all screenshots, or the Selenium log, or the test video
  • Stop a job remotely
  • Drop links to failing test videos in Campfire
  • Get faster support from support@saucelabs.com

(By the way, the following examples are for Ruby, but all these tasks are possible with other languages… Check out the ‘Download the Video’ and ‘Stop a job remotely’ examples)

Obtaining the ID programmatically

Previously, getting the session ID from a selenium-webdriver object was… well… If it was a baby, you’d tell the mother it had an “interesting” face and then immediately change the subject (here’s the discussion why).

So, you might encounter some examples like this:

## I... You... *{hurk}*
job_id = @driver.send(:@bridge).session_id

## What is this I don't even
job_id = @driver.instance_variable_get("@bridge").instance_variable_get("@session_id")

Well, none of that. Jari Bakken has added a sweet convenience method directly to the remote driver:

job_id = @driver.session_id

Using it

The session_id is just a string, so with a little bit of setting up, it becomes super easy to do all the stuff listed above.

job_id = @driver.session_id
un = Sauce.get_config[:username]
ac = Sauce.get_config[:access_key]

Provide links to jobs

puts "Your job: https://www.saucelabs.com/tests/#{job_id}"

Set Metadata with Sauce_Whisk

job = SauceWhisk.job.new(:id => job_id)
job.build = "1337"
job.save

Stop a job remotely

`curl -X PUT https://#{username}:#{access}@saucelabs.com/rest/v1/#{username}/jobs/#{job_id}/stop -d ''`

Download the video

video = `curl https://#{username}:#{access_key@saucelabs.com/rest/v1/#{username/jobs/#{job_id}/assets/video.flv -s`

Easy, huh?

Share

Guest Post: Testing JavaScript with Yeti and Sauce Labs WebDriver with Ryuichi Okumura

June 4th, 2013 by lauren nguyen

When we read YUI contributor Ryuichi Okumura‘s blog post on testing JavaScript with Yeti and Sauce, we thought it was an awesome use of Sauce, and wanted to share it with you. Ryuichi kindly gave us the green light to post-cross this, so read on to hear about how he’s using Sauce for JS testing, and check out his Twitter and Github.

We’ve recently been quite busy developing a number of JavaScript testing environments, such as test frameworks and test runners. Yeti, developed by the YUI team, is one of the test runners. As for the available test frameworks, Yeti supports the major libraries—not only YUI Test, but QUnit, Jasmine, and Mocha. I’ve shown examples previously where Yeti and QUnit were used together.

saucelabs-yui

On top of JavaScript testing, we can’t forget the devices and browsers on which the testing is being done in the first place. With the spread of so many different types of mobile devices and so many OSes and browsers in development, it’s become important to carry out tests on the actual browsers. In these conditions, services have appeared that allow you to open and operate the actual browsers online. Today, I’d like to show you a test using one of those services, Sauce Labs. Sauce Labs is a cloud service that offers many different mobile and desktop browser environments. Also, one of Sauce Labs’ major features is that it supports Selenium WebDriver protocol. Just like Yeti, since WebDriver protocol is supported, you can boot the browser on the cloud through the command line and run a JavaScript test.

First, You can sign up easy Sauce Labs account if you doesn’t have a Sauce Labs account. Sauce Labs provides some free and paid plans. Also there is “Open Sauce” plan, this is very kind and helping plan for OSS developers like you.

Sign up when you’re done, let’s prepare for the testing environment. Check your access key and download Sauce-Connect.jar file from Sauce Connect guide.

Start Sauce Connect:

java -jar Sauce-Connect.jar <username> <access key>

Install Yeti via npm command if you haven’t install yet.

npm install -g yeti

Start Yeti hub server while specify Sauce Labs WebDriver endpoint:

yeti --server --wd-url http://<username>:<access key>@ondemand.saucelabs.com:80
Yeti Hub started. LAN: http://10.0.1.13:9000
                  Local: http://localhost:9000

And, Launch browser you like while specify a test file:

yeti --browser chrome src/date/tests/unit/*.html
Waiting for Hub to launch browsers...
  Agent connected: Chrome (26.0.1410.64) / Windows 7 from 10.0.1.13
✓ Testing started on Chrome (26.0.1410.64) / Windows 7
✓ Agent completed: Chrome (26.0.1410.64) / Windows 7
✓ 22 tests passed! (35 seconds)
  Agent disconnected: Chrome (26.0.1410.64) / Windows 7 from 10.0.1.13

That’s all. It’s able to test on the browser in the cloud even if you don’t have it!

 

Share

A Browser Matrix Widget for the Open Source Community

May 30th, 2013 by Bernard Kobos

We just released a new feature that will make your project pages much more informative. It is a widget that lets you present details about your last build. It’s a more extended version of our badge that you’re probably already familiar with:

Sauce Open Sauce Badge

The browser matrix widget takes that concept to the next level. It gives you and the whole community a fast and in-depth look into the status of all tests runs that you made against different platforms using Sauce. You will find there information about each operating system (and its version), browser version, and browser vendor your test was run on. Of course you will get an indication of the status of each one of these tests – so you’ll know on which platform your test failed with a blink of an eye.

Here is how it looks:

New Sauce Labs browser matrix widget

Browser matrix widget

 

You like it? Great! Let me tell you how to use in with your open source projects.
The concept is the same as with standard status images. Just follow these few simple steps:

  1. Choose a Sauce account which corresponds to your project. If you just have one project, you can use your main Sauce account name. If you have multiple projects, you will want to create a sub-account for each project.
  2. Run your tests for a given project on Sauce using that account’s username and access key (found on the account page).
  3. Make sure to set a build and pass/fail status for every test that runs. Use process.env.TRAVIS_JOB_ID as a build number if you’re using Travis-CI. Also make sure every job is set to be publicly viewable (our Open Source Plan makes them public by default).
    If your tests don’t have a build or pass/fail status, or if even one in a build is not public, you’ll get the “Unknown” status for security reasons.
  4. Use the following HTML snippet in your GitHub readme or on your project site – just replace [ACCOUNT USERNAME] with your real Sauce username:
    <a href="https://saucelabs.com/u/[ACCOUNT USERNAME]">
    <img alt="Selenium Tests Status" src="https://saucelabs.com/browser-matrix/[ACCOUNT USERNAME].svg" />
    </a>
  5. Or if you like Markdown:
    [![Selenium Test Status](https://saucelabs.com/browser-matrix/[ACCOUNT USERNAME].svg)](https://saucelabs.com/u/[ACCOUNT USERNAME])

 

There you go – your shiny new browser matrix widget has just been placed on your project webpage. See it in action on the WD.js open source project page.

What to know more? Check out our documentation page.

Share

Guest Post: The Able Few and Qettlhup for Using GruntJS with Sauce Labs

May 28th, 2013 by lauren nguyen

Able-Logo

Our friends at The Able Few have been working on an exciting project, and they wanted to share how they’ve been using Sauce to test the product they are developing in partnership with Click with Me Now. Read on to hear more about how they integrated Sauce into their development process, and the open source GruntJS tool they built to help them use Sauce!

For the some time now, we have been developing an application over at The Able Few, a St. Louis & Indianapolis based product and software development company, called Click With Me Now. CWMN, is a no-download, co-browsing solution that allows users to share a browsing session with others in a single click.

ClickWithMeNow_Logo_CMYK_vertical_updatedIn the early stages of development, we built a series of prototypes to serve as a proof-of-concept for the application when demoed in a controlled environment. We focused most of our initial efforts around Chrome/Webkit, obviously, which allowed us to cover an impressive amount of ground in a short amount of time. When it came time to start the full build of the application, however, we had to start backfilling support for other older browsers and make sure that this didn’t impair our existing codebase or slow us to a complete halt with testing.

After weeks devoted to dealing with countless browser compatibility issues, mostly in IE, and many profanity laced insults hurled at the computer gods, we had a working prototype that functioned in at least the latest version of every browser. Of course that wasn’t good enough and going forward we were going to need to be able to test the app in every other browser known to man.

We started writing out some Selenium and Capybara tests. This allowed us to do things like disable Websockets and Flash, in order to make sure that the application didn’t crash and burn, which we could test in Chrome, Firefox, and Safari without a hitch — but not IE! Also, what about mobile? Oh, and what would happen if the Host was using an old version of Firefox and the Guest was using a Webkit nightly? As these questions began to pile up, our aspirations of adequately testing our application began to sour. We played around with VirtualBox VMs, but it quickly became apparent that the number of OS and browser variants we needed would become a nightmare to manage, not to mention the licensing costs. We also needed to think about mobile devices, older versions of OSX, Linux, and myriad other combinations that we had yet to consider.

It was a lot to deal with and we certainly felt the pressure of needing to accomplish this in a timely manner. Then by a stroke of luck we came across Sauce Labs.

The Guest, in general, has a lower set of requirements. The relationship between the host and one or more guests make testing this application a real chore with significantly more points of failure than a typical web application.
clickwithmenow2

Since we already had a good amount of test coverage in Selenium using Ruby, the effort required to integrate our existing tests with Sauce Labs was pretty minimal. Obviously, it defeats the purpose if all the testing isn’t automated, so we made it possible to pass arguments to our tests and instead of just running `ruby spec/test.rb` we are running `ruby spec/test.rb windows8firefox17`, and so on.

To further automate this, we created a JSON file that contained all of the browser/OS combinations that we wanted to test, along with the data that the Sauce Labs API needed. Of course, a couple of weeks later, we found out that Sauce Labs already has an up-to-date list available — one day we may update our code to use their version, but for now, our method does what we need it to do.

Now, we needed to parse the JSON into actual “identities” and we needed Ruby to understand those arguments. Being that I’m a JavaScript developer with a long history of PHP, let’s just say that my Ruby isn’t the best, but I needed to solve a problem. So, with the test code in hand, I took a stab at a solution. We ended up with something that actually worked better than I could have expected.

By updating `BrowserList.json` to point to your local JSON file from above you can test this code out, too — well, as long as your environment is setup and ready to run Sauce Labs tests with Selenium and Capybara. Just a couple updates to your Gemfile and a quick read through Sauce Labs’ ‘Getting Started’ guide in their Documents should get you started

Still, with all of this done, we were having to go through each and every browser by hand and run the Ruby spec tests, which you can imagine was pretty time consuming. This is where JavaScript came to the rescue! Thanks to Bocoup’s GruntJS, running automated tasks is now a no-brainer. Simply build a Gruntfile, give it a few lines of code, run a command, and lean back in your chair as your computer actually does the hard work. Or, in our case, dedicate a machine to running these tests because it’s going to take a LONG time.

Currently, there are no official methods of using Grunt with Sauce Labs so we decided to build our own solution and open source it. Qettlhup, Klingon for “sauce”, is an automated tool built on GruntJS that facilitates the testing of browsers in Sauce Labs using a JSON object.

Once you’re familiar with GruntJS — which you should be, because it is awesome — you will quickly see how it works. You simply pass it the language of the tests that you want to run, the path to the file that contains the tests, and the JSON file that lists all of the browsers that you want to run the tests against. In the case of CWMN we have two sets of tests, one for the Host and the other for the Guest, which both have their own requirements, so we pass Qettlhup another task in the same object and we’re ready to go. You can see examples of setting up single and multiple tasks on the Qettlhup README.

Now, we just type a single command — `grunt qettlhup` — and away it goes, running all of our tests for us and giving feedback on each set of tests as they run. The process will stop as soon as it hits an error, which gives us the opportunity to fix the problem and to test that fix against a specific browser outside of Qettlhup. Once the error has been resolved, we can go back and run our battery of tests again.

All of that said, even with our huge library of tests, custom GruntJS automation tool, and knowledge of Selenium and Capybara, none of this would have been possible without Sauce Labs. It is a utility that has saved us countless hours of manual processing and testing and has provided us with fantastic reporting and feedback. Each test even includes archives of image and video references. There is no telling where we would be if Sauce Labs wasn’t around! We couldn’t recommend their testing platform more and are looking at it with every build we do in the future.

Share

Automated Mobile App Testing with Python and Nose

May 16th, 2013 by Jason Carr

One of the coolest parts about using Appium for automated functional testing is that you can write your tests in whatever language has the testing tools that suit you best. One of the most popular choices for testing is Python. Writing tests for iOS and Android apps with Appium and Python is easy.

In this post we’ll walk through the steps involved in testing an iOS sample app using Appium’s Python example tests, but the steps for running tests on android are very similar.

To start, fork and clone Appium from https://github.com/appium/appium, and follow the installation instructions to set up Appium on your machine.

We’ll need to install Appium’s dependencies and build the sample apps. To do this, run the following command from the Appium working directory:

$ ./reset.sh --ios

Once the project is built, you can start Appium by running:

$ grunt appium

Now that Appium is running, switch to the sample-code/examples/python directory. Install the dependencies with pip (if you are not in a virtualenv, you will need to use sudo):

$ pip install -r requirements.txt

Then, run the example test:

$ nosetests simple.py

Now that you’re set up to run tests, let’s take a closer look at the example test that we just ran to get an idea of how Appium works. This test launches our demo app, fills in some boxes, clicks a button, and checks for an expected result. First, we create the test class and a setUp method:

class TestSequenceFunctions(unittest.TestCase):

    def setUp(self):
        app = os.path.join(os.path.dirname(__file__),
                           '../../apps/TestApp/build/Release-iphonesimulator',
                           'TestApp.app')
        app = os.path.abspath(app)
        self.driver = webdriver.Remote(
            command_executor='http://127.0.0.1:4723/wd/hub',
            desired_capabilities={
                'browserName': 'iOS',
                'platform': 'Mac',
                'version': '6.0',
                'app': app
            })
        self._values = []

The “desired_capabilities” parameter is used to specify the platform (iOS 6.0) and the app we want to test. Next we’ll add a tearDown method to send the quit command after each test:

    def tearDown(self):
        self.driver.quit()

Finally, we’ll add a helper method that fills in the forms, and the main test method:

    def _populate(self):
        # populate text fields with two random number
        elems = self.driver.find_elements_by_tag_name('textField')
        for elem in elems:
            rndNum = randint(0, 10)
            elem.send_keys(rndNum)
            self._values.append(rndNum)

    def test_ui_computation(self):
        # populate text fields with values
        self._populate()
        # trigger computation by using the button
        buttons = self.driver.find_elements_by_tag_name("button")
        buttons[0].click()
        # is sum equal ?
        texts = self.driver.find_elements_by_tag_name("staticText")
        self.assertEqual(int(texts[0].text), self._values[0] + self._values[1])

That’s it! There are more Python examples in Appium’s sample tests. Please let us know if you have any questions or comments about running Appium’s tests with Nose and Python.

Share

Steve Hazel on FLOSS Weekly

May 10th, 2013 by lauren nguyen

Our co-founder and VP of Product Steven Hazel was interviewed this week on FLOSS Weekly, the seminal weekly open source podcast. If you didn’t catch the show live, you can watch or listen here, and hear Steve talk Appium, Sauce Labs, and his love of Emacs. Steve joins a long list of distinguished open source guests, including Sauce co-founder Jason Huggins, who’s been on the show to talk about Selenium.

 

Share