Weekly Wednesday Webinar on Selenium & Sauce Labs

I’ve been working at Sauce Labs for a while now, helping enterprise users build test automation frameworks and implement continuous integration using Selenium & Sauce Labs.

In order to reach a larger audience — and to learn more about people’s challenges developing test automation — I’m going to be hosting a weekly webinar on using Selenium with Sauce Labs for test automation.

So, starting this week, each Wednesday during lunch (12:30pm Mountain Time) I’ll host a webinar / office hours.  I’ll begin with a brief presentation introducing the topic, followed by a demo (live coding — what could go wrong?), and then open it up for questions & comments.

The first webinar will be tomorrow at 12:30pm MST.  The topic is DesiredCapabilities.

I’ll talk about what desired capabilities are, how to use desired capabilities with Sauce Labs, and show how you can use the  Sauce Labs platform configurator to generate desired capabilities.  I’ll also talk about Sauce Labs specific capabilities used to report on tests and builds.

Register on EventBrite here: Selenium & Sauce Labs Webinar: Desired Capabilities

Join the WebEx directly: Selenium & Sauce Labs Webinar: Desired Capabilities

Contact me if you’d like a calendar invite or more info.

Testing PDF downloads with Sauce Labs

There are 2 main challenges to testing PDF downloads with Sauce Labs:

1. Testing PDFs in the browser are not supported by Selenium.
2. Download dialogs are native UI elements and not supported by Selenium.

A PDF file may try to open in a PDF plugin, which cannot be accessed by Selenium. But, even if you change your browser configuration to download PDF files automatically, as described here:


Sauce Labs does not provide access to the file system on our VMs. So, in order to test a PDF you would need to download it locally. The best practice is to get the URL of the link using Selenium and then to download it using wget, curl, or your favorite HTTP library.

See this blog post which goes into further detail:


Testing mobile apps in the cloud

There are several services available for testing mobile apps in the cloud on real devices:

Sauce Labs

Sauce Labs is the veteran and was co-founded by Jason Huggins, the original creator of Selenium.  Sauce Labs also works on development of Appium.


BrowserStack is an economical choice for testing in the cloud, but while the offer “Live” mobile devices (manual testing only), it does not appear that they offer devices for test automation.

Xamarin Test Cloud

Xamarin is a pretty good contender, but focuses their tooling around Microsoft .NET / Visual Studio developers.  It does not appear that Appium is supported (directly) Still, they have a big selection of devices for those willing to stick to Microsoft tooling. It is also nice that their metering is a soft limit.

Perfecto Mobile

Perfecto Mobile has been around for a while as a service for Enterprises.  It is proprietary, but also supports Appium.  It comes with an Enterprise level price though.  You have to call and talk to a salesperson for any plan beyond proof of concept.

Keynote Mobile Testing

Keynote Mobile Testing used to be called Device Anywhere and their experience dates back to the days before smart phones.  I don’t have recent experience with them, but they used to offer only pixel based automation.  It appears they support Appium now.  But automation is not supported outside their enterprise sales channel.

Amazon Device Farm

Amazon Device Farm is the most recent entry in the field.  But it is not only quite expensive, but requires a lot of do-it-yourself.  Perhaps it will be more practical once tooling for recipes becomes available.


Price Comparision of Sauce Labs, Xamarin Test Cloud, Perfecto Mobile, & Amazon Device Cloud

Service Price Device time Concurrent Devices
Sauce Labs $129/month* 1000 minutes 4
$259/month* 2000 minutes 4
399/month* 3000 minutes 6
$499/month* 4000 minutes 8
Xamarin Test Cloud $99/month** 1 hour/day 1
$379/month** 5 hours/day 3
$799/month** 10 hours/day 5
Perfecto Mobile $399/month* 20 hours 1
Amazon Device Farm $0.17/minute 1
Amazon Device Farm $250/month unlimited 1

* 25% annual discount available

** 15% annual discount available

Setting system properties with Gradle

In Java you can pass system properties from the command line like this:

java -D MyProperty=foo MyClass

And you can then get them in your code like so:

public class MyClass {
  public String getMyProperty() {
    return System.getProperty("MyProperty");

Pretty easy, no?

You can pass system arguments the same way with Gradle:

gradle -D MyProperty=foo run

But what if you want to manipulate or use those properties in Gradle first?

Instead of -D you can use -P to pass properties to the Gradle object, and then you can do whatever you want with it.

gradle -P MyProperty=foo MyClass

And then you can use your properties in Gradle and then pass them to the System properties thusly:

task setProperty << {

    if (project.hasProperty("ENV")) {
        println "project has property ENV"
        System.properties["ENV"] = "$ENV"
    } else {
        println "project does not have property ENV"
        System.properties["ENV"] = "dev"

    println "ENV: " + System.properties["ENV"]


Some references:






When should you use BDD

1. Product and dev are talking to each other
2. You want to write something down to communicate
3. You want to read something to communicate
4. You don’t use documents as a way to avoid communicating.
3. You can come up specific examples of requirements
4. You are willing to test those requirements frequently
5. You will pay attention to the results of those tests
6. You are willing to update those requirements when they change
7. You want to execute tests automatically
8. You have an environment and data that enables you to test changes immediately.
9. You have a build and deploy process that enables you to deploy when any change is made.
10. You don’t think BDD is a way to solve any of these problems.

Who wants to write unit tests?

Who wants to write unit tests?

Not me.

It’s like asking who wants to eat healthy. We all know (or suspect) that it’s good for you, but what are the real benefits?

Writing unit tests is extra work, and not very fun.  And if you start with an existing code base that doesn’t have them, it can be intimidating and frustrating to get started.  And it isn’t always easy.  You might have to spend significant time refactoring and writing mocks and other test doubles to be able to test your code.


If you’re skeptical of the value of unit tests, come share your reasons.

If you write unit tests but find they don’t have any real value (or not enough to justify the costs) then let’s talk about why you do it.

If you want to write unit tests, but can’t find the time, or feel like you need help getting started, let me know, and I’ll be your personal trainer.  Book some 1 on 1 time with me.

If you love writing unit tests and the productivity boost and code quality gains they provide, don’t bother coming, unless you want to help convince others.

There are real challenges to writing unit tests but don’t let procrastination or fear be one of them.


I’ll be hosting a webinar about unit testing today at 1pm at Hart.com and next Wednesday at 1pm Pacific for everyone online.

Here’s the hangout url https://hangouts.google.com/hangouts/_/one-shore.com/whowantstowriteunittests?hl=en&authuser=0

Ping me if you want an invite in your calendar.