Making Your App Testable

September 16th, 2016 by Dan Cuellar

When writing test automation, one of the most important factors for determining the amount of time and resources you will consume (and ultimately the success or failure of the endeavor) is the testability of your application. By testability, I’m referring to how the app interacts with UI (and other) automation frameworks, the ease by which a test script can setup the scenarios you wish to test, and how you make your tests safe for concurrency.

Making Elements Accessible

Let’s address the matter of controlling your application with automation frameworks first. Given that you are reading this blog, it is likely you are using either Selenium or Appium as your automation framework, so this blog post will only address these frameworks.

Web Content (Selenium)

Let’s start with Selenium. In order for your web app to be easily controlled by Selenium, you need to think ahead as to how you will identify important pieces of the DOM when constructing tests. Selenium provides many means by which you can do this, called “Locator Strategies”. Some are better than others. You should consider which of these you will be using in your tests as you develop the user interface. Ideally, each element would have an ID attribute applied directly to the tag for any element that the test will exercise.

Sometimes, for one reason or another, you may not be able to use an ID. If this is the case, the next recommended technique is to use a CSS selector. If your web app is developed with good principles, such as BEM (Block Element Modifier), it is likely easier to automate as it should have a relatively short globally unique CSS selector. If it does not, I would not recommend adding a CSS class just for automation, as it isn’t the purpose of the styling language to do automation. Rather, I would suggest that you use an HTML  data-* attribute. You can use the CSS selector locator to grab an element by one of these attributes, but the good news is you aren’t adding unnecessary classes to your CSS, and the purpose of the HTML attribute will be much clearer. (more…)

Recap: Selenium and Appium Training Courses from Sauce Labs (Webinar)

August 5th, 2016 by Bill McGee

Thanks to everyone who joined us for our recent webinar, “Selenium and Appium Training Courses from Sauce Labs“, featuring Sauce Labs’ Director of Product Marketing, Ken Drachnik, and Automation Specialist Kevin Berg.

In this webinar, Ken and Kevin announced the availability of our three new technical training programs – Selenium 101, Appium 101, and Sauce Labs Onboarding. They reviewed the course curriculum and class format, and gave a brief demo of the course environment. They also covered classes that are currently in development – Selenium 201, Appium 201 and Sauce Labs for Enterprise.

Interested in learning more about our new training courses? You can find more information on our training website.

Access the recording HERE and view the slides below: 

New – Selenium & Appium Training Courses from Sauce Labs!

August 3rd, 2016 by Ken Drachnik

In our ongoing effort to help developers and QA professionals quickly get up to speed with Selenium and Appium, we’re thrilled to announce the availability of our three new technical training programs – Selenium 101, Appium 101, and Sauce Labs Onboarding. Led by our experts, with in-depth knowledge of Selenium and Appium, class sizes are small and include lectures, demos, and interactive hands-on exercises.

Selenium 101 & Appium 101

Both the Selenium and Appium courses are available in several different formats. Instructor-led training is available both online and on-site, and features public curriculum available to all, or you can request a dedicated course that is customized to your specific business requirements.

  • Selenium 101 introduces you to the Selenium automation API for testing web applications on desktop browsers
  • Appium 101 introduces you to the Appium automation API for testing web applications on desktop and mobile browsers, and for testing native and hybrid applications on mobile emulators, simulators, and real devices.

Sauce Labs Onboarding

Sauce Labs Onboarding is a free, one-hour self-paced class designed to introduce you to Sauce Labs features to get you up and running with your tests.

In addition to providing you the nuts and bolts of automated testing, our courses also cover best practices and useful how-to tips, so you can start testing right away, and then develop better tests in a lot less time.

First classes begin August 17th – sign-up here or request more information.

Happy learning!

Appium 1.5.3 Released on Sauce

June 8th, 2016 by Isaac Murchie

We are pleased to announce the release of Appium 1.5.3 through npm and on Sauce Labs!

Appium 1.5.3 is primarily a bug-fix release. However, it also adds functionality to support for iOS WKWebViews and for automating the iOS Calendar app, as well as adding a capability to use abd for screenshots in Android web/hybrid sessions, and providing a list of Android activities to wait for on session startup.

General

  • Fix handling of statuses from proxied drivers (Chrome, Selendroid, etc.).
  • Fix intermittent bug where creating a directory might crash the server.

iOS

  • Add support for WKWebView-based webviews.
  • Add support for automating the built-in Calandar app.
  • Fix bug where scrolling in Safari would crash.
  • Fix handling of Safari in “new window” state.
  • Fix handling of arguments for keys method so that clients that send an array do not fail.
  • Clean up handling of ipa files for real device tests.
  • Make sure processArguments parsing works.

Android

  • Add nativeWebScreenshot capability, to use adb screenshots instead of ChromeDriver if necessary.
  • Add support to auto-select device based on platformVersion rather than using first available device.
  • Allow appWaitActivity to be a list of activities.
  • Fix setting wifi and data state.
  • Implement initAutoWebView capability.
  • Report appPackage, appActivity, and deviceUDID when requesting session details, so tests have more information about running state.
  • Make sure unlock app is closed at the end of a session so that the device works again.
  • Fix handling of unlock to make less flakey.
  • Make sure unicode encoding works correctly when strings are long.
  • Fix handling of disableAndroidWatchers capability.
  • Fix bug where early ChromeDriver failure crashed Appium.

Appium 1.5.2 Released on Sauce

April 26th, 2016 by Isaac Murchie

We are pleased to announce the release of Appium 1.5.2 through npm and on Sauce Labs! This is a bug fix release that deals with many issues with 1.5.1, including a major bug where large Android applications would cause Appium to run out of memory and die.

General

  • deprecated --command-timeout. Use newCommandTimeout desired capability instead
  • ensure implicit wait can be set through timeout method
  • add better logging for EPIPE errors

iOS

  • make sure ipa files are handled correctly for installing on real devices
  • ensure that existing SafariLauncher on device is used instead of rebuilding and reinstalling
  • fix issues with getting webview contexts on real devices
  • add full timeout support through timeout method
  • make sure Xpath searches respect implicit wait timeout
  • make sure bare Instruments process arguments are accepted

Android

  • fix failure when apk file is too large
  • re-implement setting geolocation so it does not use Telnet
  • add support for Chromium browser
  • fix issues with flick
  • fix bug where touch action release would throw an error
  • fix bug in later Android SDK version where noticing a newly started avd would fail
  • implement autoWebviewTimeout

Appium 1.5.1 Released on Sauce

March 29th, 2016 by Isaac Murchie

We are happy to support the newly-released Appium 1.5.1. This release fixes a
number of issues with 1.5.0, including one bug that prevented some frameworks
from correctly polling for status during Safari tests.

General

  • allow `platformName` to be any case
  • Windows process handling is cleaned up
  • Desired capabilities `language` and `locale` added

iOS

  • iOS 9.3 (Xcode 7.3) support
  • Fix handling of return values from `executeScript` in Safari
  • Don’t stop if Instruments doesn’t shut down in a timely manner
  • Escape single quotes in all methods that set the value on an element
  • Allow custom device names
  • Make full use of process arguments to Instruments
  • Pass `launchTimeout` to Instruments when checking devices

Android

  • Make use of `–bootstrap-port` server argument
  • Fix `keystorePassword` capability to allow a string
  • Fix handling of localization in Android 6
  • Use Appium’s unlock logic for Chrome sessions
  • Make sure reset works
  • Make unlock more reliable for later versions of Android
  • Allow Xpath searching from the context of another element
  • Make full use of process arguments to adb
  • Better error messages when ChromeDriver fails to start

Appium 1.5 Released on Sauce Labs

February 26th, 2016 by Jonathan Lipps

Appium 1.5

The Appium team is extremely proud to announce the release of Appium 1.5! Appium 1.5 has been in the works for over half a year, and we would like to share why it’s such an important release for us. Appium 1.5 is primarily a technical rearchitecture. As the project grew from infancy through to 1.0 and beyond, the core team did their best to keep the code organized, to keep it easy for new contributors to come to the project, and to fix bugs and add features in a timely fashion. However, as is the case with many software projects, the time came when despite our best efforts, Appium’s fundamental architecture was working against us, not with us.

Given the relatively stable nature of the project in the 1.4.x series, we felt it was a good time to invest in the future velocity of Appium’s development. When we began work on Appium 1.5 we had the following goals:

  • Take a hard look at the current code organization and reconceptualize the relationships between different subsections of Appium with an eye to making distinctions clearer and concerns more separate.
  • Leverage the NPM ecosystem’s best practices and break Appium up into packages based on responsibility, maintenance, etc…, whenever appropriate.
  • Rewrite the entire codebase from ES5 JavaScript to ES2015 JavaScript with async/await (and in so doing wipe away a huge source of hard-to-trace Appium bugs).
  • Standardize subprocess management. Appium is basically a combination API server and subprocess manager (we manage instruments, uiautomator, chromedriver, selendroid, etc…), and so standardizing subprocess management makes our code cleaner and more readable throughout the project.
  • Abstract common driver behavior: Appium’s IOS support and Android support really derive from the same common interface, so we wanted to factor that interface out to reduce duplication of work and boilerplate across Appium’s different drivers.
  • Clean up our build process so that we are not using a handful of different build tools in different situations. Ensure we’re running CI at the subpackage level to save time when releasing Appium.
  • Create a more friendly architectural environment for new devs to contribute to Appium. Make sure that one type of change needs to happen in one place and that READMEs abound.
  • …and many more very specific technical goals. For more information on how Appium is now put together from a developer perspective, see our developer’s overview.

(more…)

Recap: 10 Things You Didn’t Know About Appium + What’s New in Appium 1.5 [Webinar]

February 17th, 2016 by Bill McGee

Thanks to everyone who joined us for our recent webinar, “10 Things You Didn’t Know About Appium + What’s New in Appium 1.5”, featuring Dan Cuellar, the creator of Appium. In his presentation, Dan shares 10 secrets about Appium that you may have never heard before, and also discusses what’s new in Appium 1.5 and what’s on the road map for the rest of 2016.

The presentation also showed:

  • Tips and tricks for better leveraging Appium for your mobile app testing
  • What’s new in Appium 1.5
  • Appium Roadmap
  • Live demo – how to add visual testing to your Appium tests, leveraging devices on the cloud

Missed the presentation, want to hear it again, or share with a colleague?

Access the recording HERE and view the slides below.

Looking to get started with Appium? Download our free Appium Bootcamp by Dave Haeffner.

Appium + Sauce Labs Bootcamp: Chapter 4, Advanced Desired Capabilities

August 18th, 2015 by Jonathan Lipps

This is the fourth in a series of posts that discuss using Appium with Sauce Labs. Chapter 1 covered Language Bindings; Chapter 2 discusses Touch Actions; Chapter 3 reviews Testing Hybrid Apps & Mobile Web; and this installment is about Advanced Desired Capabilities.

Appium, by and large, supports the desired capabilities you’re familiar with from Selenium. However, given that it also exposes mobile-specific functionality, we have some mobile-specific desired capabilities. We even have capabilities that are specific to one mobile platform: iOS or Android. For the full list of capabilities Appium supports, please see the capabilities doc.

Environment-specifying Capabilities

The main differences you’ll recognize will have to do with selecting which type of mobile environment you want to automate. Appium has adopted the “Selenium 4″ style of session capabilities, which means that, instead of capabilities like this, for example:

[code language=”javascript”]
{
browserName: ‘safari’,
version: ‘6.0’
}
[/code]

You would specify the following, for Mobile Safari on iOS 7.1:

[code language=”javascript”]
{
platformName: ‘iOS’,
platformVersion: ‘7.1’,
deviceName: ‘iPhone Simulator’,
browserName: ‘safari’
}
[/code]

The new capabilities platformName, platformVersion, and deviceName are _required_ for every session. Valid platforms are iOS and Android.

To automate a native or hybrid app instead of a mobile browser, you omit the browserName capability and include the app capability, which is a fully-resolved local path or URL to your application (.app, .ipa, or .apk). For example:

[code language=”javascript”]
{
platformName: ‘Android’,
platformVersion: ‘5.0’,
deviceName: ‘Android Emulator’,
app: ‘/path/to/my/android_app.apk’
}
[/code]

Sometimes we might want to run an Android test on an older device, and so we need to use Appium’s built-in Selendroid support for older devices. To specify that you want to use the Selendroid backend, keep everything else the same, but specify the automationName capability, as follows:

[code language=”javascript”]
{
automationName: ‘Selendroid’,
platformName: ‘Android’,
platformVersion: ‘5.0’,
deviceName: ‘Android Emulator’,
app: ‘/path/to/my/android_app.apk’
}
[/code]

And of course, if you’re running any tests on Sauce Labs, make sure to specify the version of Appium you’d like to use with the appiumVersion capability:

[code language=”javascript”]
{
platformName: ‘Android’,
platformVersion: ‘5.0’,
deviceName: ‘Android Emulator’,
browserName: ‘Browser’,
appiumVersion: ‘1.3.4’
}
[/code]

(more…)

Appium + Sauce Labs Bootcamp: Chapter 3, Working with Hybrid Apps and Mobile Web

July 6th, 2015 by Isaac Murchie

This is the third in a series of posts that discuss using Appium with Sauce Labs. Chapter 1 covered Language Bindings; Chapter 2 discusses Touch Actions; this chapter covers Testing Hybrid Apps & Mobile Web; and Chapter 4 is about Advanced Desired Capabilities.

Mobile applications can be purely native, or web applications running in mobile browsers, or a hybrid of the two, with a web application running in a particular view or set of views within a native application. Appium is capable of automating all three types of applications, by providing different “contexts” in which commands will be interpreted.

Contexts

A context specifies how the server interprets commands, and which commands are available to the user. Appium currently supports two contexts: native and webview. Both of these are handled by different parts of the system, and may even proxy commands to another framework (such as webviews on Android, which are actually served by a managed ChromeDriver instance). It is important to know what context you are in, in order to know how you can automate an application.

Native contexts

Native contexts refer to native applications, and to those parts of hybrid apps that are running native views. Commands sent to Appium in the native context execute against the device vendor’s automation API, giving access to views and elements through name, accessibility id, etc. As well, in this context commands to interact directly with the device, to do operations such as changing the wifi connect or setting the location, can be used. These very powerful operations are not available within the context of a webview.

In addition to native and hybrid applications, the native context can be accessed in a mobile web app, in order to have some of the methods only available there. In this case it is important to understand that the commands are not running against the web application running in the browser, but rather are interacting with the device and the browser itself. (more…)