Posts Tagged ‘Best Practice’

Should You Have a Dedicated Automation Team Within Your QA Department?

September 1st, 2015 by Israel Felix

If you’ve led or managed QA teams that have included an automation test team, you’ve probably been in a situation where you had to decide whether you should keep them on board. Normally the decision needs to be made when there is a change in leadership, wherein the new management comes with a mandate to consolidate groups and reduce costs. This situation also tends to arise when working with startups or small companies when they are ready to put together or augment their QA teams. So should you have a dedicated automation team?

Typically, there are two camps with regards to dedicated automation teams. There are those who believe that we should have dedicated automation teams, and those who believe that QA engineers should handle manual testing and automation testing. From my experience working in QA within both small and large companies, I almost always prefer to have a dedicated automation team. However, there are a few scenarios where having a QA team that takes on both roles might make sense.

Time to Market

For automation to be done right, it needs to be a full-time job. From developing the framework and creating the libraries and scripts for different platforms to executing and debugging failures — it will all simply consume too much of an engineer’s time and compromise the actual testing and release date. As you already know, time to market and keeping a release on schedule is top priority, so testing needs to get done, no matter what. (more…)

Building Applications for Quality

August 20th, 2015 by Zachary Flower

As developers, when building new projects from the ground up, we have a tendency to shoot first and ask questions later. Facebook popularized this attitude with their old motto, “Move Fast and Break Things,” and it’s a notion that seems to have been firmly embedded into startup culture. Unfortunately what often happens is that once things get broken, we fix them with Band-Aids and duct tape in order to keep up the fast pace we’ve established. While we often put a premium on the end result, the foundation we build to achieve that result is just as important.

For every line of hacky code we write, even if it does what it’s supposed to, we are compounding the amount of work that future developers on a project will have to do when you feel your company is finally in a place to “do it right.” In the face of legacy code, we will always be pushed to compromise quality for speed, but it is important to communicate the true impact code debt has on the future of a project. Eventually, Facebook learned this lesson, changing their motto last year to “Move Fast with Stable Infra(structure).” By putting an emphasis on stability, Facebook essentially enacted a speed limit on development to encourage bug-free code.

So, how do we balance speed and quality? The answer, unsurprisingly, is by establishing a set of rules and processes for you and your team to follow. Before beginning any work on a new application, it is important to lay the proper groundwork. This is the time to set up your deployment processes, version control management workflow, and unit test frameworks. In addition, you should be using this time to build out your code style guide and plan your application architecture. (more…)

The Benefits of Parallel Testing

August 6th, 2015 by Greg Sypolt

Running in slow motion?

Are you running, but can’t make your feet move as fast as you want them to? This is a common feeling among beginners, as well as experienced automation developers. As your regression suite grows, it takes longer to run tests, and soon you have a problem because your regression suite is running longer and longer. There are a few approaches to smarter testing: reduce the number of tests, only run the tests applicable to the change, or optimize the test execution.

Marching toward continuous integration

As your software development team marches toward Continuous Integration (CI), the process involves a lot of automated testing. Even automated testing consumes precious time, so you need to ensure your automated tests are designed to scale. If a particular change is going to cause one or more tests to fail, the team needs to know about it as quickly as possible. Developing scripts to be lean and independent allows for fast feedback to developers.

Let’s unleash the power of parallelization

Use parallelization to speed up slow automated UI tests, and set a standard to develop lean and independent starts. A single cucumber scenario can easily take minutes to run. When you have a lot of scenarios, they can quickly compound your suite and take several minutes or hours to complete. No one wants slow automated tests — tests so slow that they only run a couple of times per day. Everyone expects automated tests to be launched for every build and send feedback within minutes, not hours. Set a standard for every build: the test execution must complete and send feedback within 10 minutes. (more…)

Test Automation Link Round-Up

November 13th, 2014 by Bill McGee
The Internet was kind to us last week. Here’s a quick round-up of some pieces on automated testing, Appium and other mobile test tools, and Sauce Labs. See below for snippets and links to the full articles.

 

Mobile testing tools are experiencing a growth spurt. New products and services emerge nearly every day, and the time and energy needed to evaluate them may make all the free trials in the world seem not so free. This article looks at several mobile testing tools, listing their benefits, features and tradeoffs to help testers and IT managers make smarter investment decisions. 
Click HERE to read more.

 

This guide provides a compendium of Selenium WebDriver resources to help beginners or advanced users learn about the Browser Test Automation framework. The guide also includes various other platforms and tools that allow you to build out a Test Automation Framework.
Click HERE to read more.

 

Use of automated testing software is gaining popularity for many reasons. Automated software testing enables an organization to leverage technology to perform mundane repetitive tasks efficiently, saving both time and cost. Another side effect of automating your test is that It gives you more time to create tests, increasing overall test coverage. However, these benefits come at a cost. Data shows that about 80% of Automation initiatives fail for various reasons. To ensure that the test automation is successful and offers maximum ROI, one should follow certain best practices. 
Click HERE to read more.
Have an idea for a blog post, webinar, or more? We want to hear from you! Submit topic ideas (or questions!) here.

HomeAway + Sauce Labs: Continuous Delivery Made Awesome [VIDEO]

October 7th, 2014 by Bill McGee

A few weeks back, we sat down with Carl Shaulis at HomeAway to learn how they leverage Sauce Labs‘ cloud in their testing process.

HomeAway, Inc. is the world’s leading online marketplace for the vacation rental industry. With over one million live vacation rental listings in 190 countries paired with a family of 50 websites and hundreds of applications thanks to a series of acquisitions, quality is their top priority. To get ahead of the curve, Carl’s team is trying to automate and use best practices like continuous integration as much as possible. We were also thrilled to hear that they’re using Appium, a cross-platform test automation framework powered by Sauce Labs, for their mobile testing.  Carl also says Sauce fits perfectly into their testing process.

Watch the video below to learn more about their path towards continuous delivery, and how Sauce fits into that story.

(more…)

Re-Blog: Building Markdown-Based Developer Docs

August 13th, 2014 by Bill McGee

Sauce Labs developer Chris Wren and his team have been working tirelessly to improve our documentation system, so we thought we’d share what they’ve been up to. Says Chris:

“Recently at Sauce Labs we decided to retool our documentation system. This decision came after accumulating docs in a number of template systems and repos which were difficult to standardize and maintain. The result of this effort was a new markdown-based docs site available at docs.saucelabs.com.”

For all the details, be sure to check out Chris’ post – just click the image below to view.

Building markdown-based developer docs

Want to contribute to Sauce Labs’ documentation? In the spirit of open source, we’ve housed them in GitHub. Submit away.

Appium Bootcamp – Chapter 7: Automate Your Test Runs

August 12th, 2014 by Bill McGee

appium_logoThis is the seventh post in a series called Appium Bootcamp by noted Selenium expert Dave Haeffner.

Read:  Chapter 1 Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 | Chapter 7

Dave recently immersed himself in the open source Appium project and collaborated with leading Appium contributor Matthew Edwards to bring us this material. Appium Bootcamp is for those who are brand new to mobile test automation with Appium. No familiarity with Selenium is required, although it may be useful. This is the seventh of eight posts; two new posts will be released each week.

To make our tests as useful as possible, we’ll want to automate when they get run. To do that, we’ll use a Continuous Integration (CI) Server.

A Continuous Integration Server Primer

A Continous Integration server (a.k.a. CI) is responsible for merging code that is actively being developed into a central place (e.g., “trunk” or “master”) frequently (e.g., several times a day, or on every code commit) to find issues early so they can be addressed quickly — all for the sake of releasing working software in a timely fashion.

With CI, we can automate our test runs so they can happen as part of the development workflow. The lion’s share of tests that are typically run on a CI Server are unit (and potentially integration) tests. But we can very easily add in our automated mobile tests.

There are numerous CI Servers available for use today. Let’s pick one and step through an example.

A CI Example

Jenkins is a fully functional, widely adopted, and open-source CI server. It’s a great candidate for us to step through.

Let’s start by setting it up on the same machine as our Appium Server. Keep in mind that this isn’t the “proper” way to go about this — it’s merely beneficial for this example. To do it right, the Jenkins server (e.g., master node) would live on a machine of its own.

Quick Setup

A simple way to get started is to grab the latest Jenkins war file. You can grab it from the Jenkins homepage, or from this direct download link.

Once downloaded, launch it from your terminal.

java -jar /path/to/jenkins.war

 

You will now be able to use Jenkins by visiting http://localhost:8080/ in your browser.

Running Tests Locally

After loading Jenkins in the browser, we’ll create a Job and configure it to run our Appium tests. Let’s start with the Android tests first.

  1. Click New Item in the top-left corner
  2. Type a name into the Item name input field (e.g., Appium Android)
  3. Select Build a free-style software project
  4. Click OK

This will load a configuration screen for the Jenkins Job.

 

  1. Scroll down until you reach the Build section (near the bottom of the page)
  2. Click Add build step
  3. Select Execute shell
  4. Input the following into the Command input box
cd /path/to/your/appium/test/code
bundle update
rake android

In this set of commands we are telling Jenkins to change directories to our test code, make sure we have the necessary libraries, and then launch the Android tests.

Click Save at the bottom of the page, make sure your Appium Server is running (if not, load up the Appium GUI and click Launch), and click Build Now on the left-hand side of the Jenkins Job screen.

Once it’s running, you can click on the job under Build History, and then click Console Output (from the left-hand panel). In it, you should see something similar to this:

Started by user anonymous
Building in workspace /Users/tourdedave/.jenkins/jobs/Appium Android/workspace
[workspace] $ /bin/sh -xe /var/folders/yt/h7v9k6px7jl68q81c9sqrd9h0000gn/T/hudson6140596697737249507.sh
+ cd /Users/tourdedave/Dropbox/_dev/appium/appium-getting-started/code-examples/7/1
+ bundle update
Fetching gem metadata from https://rubygems.org/...........
Fetching additional metadata from https://rubygems.org/..
Resolving dependencies...
Using rake 10.3.2
Using awesome_print 1.2.0
Using json 1.8.1
Using mini_portile 0.6.0
Using nokogiri 1.6.3.1
Using ffi 1.9.3
Using childprocess 0.5.3
Using multi_json 1.10.1
Using rubyzip 1.1.6
Using websocket 1.0.7
Using selenium-webdriver 2.42.0
Using blankslate 2.1.2.4
Using parslet 1.5.0
Using toml 0.1.1
Using appium_lib 4.0.0
Using bond 0.5.1
Using coderay 1.1.0
Using method_source 0.8.2
Using slop 3.6.0
Using pry 0.9.12.6
Using numerizer 0.1.1
Using chronic_duration 0.10.5
Using spec 5.3.4
Using appium_console 1.0.1
Using diff-lcs 1.2.5
Using mime-types 1.25.1
Using rdoc 4.1.1
Using rest-client 1.6.8
Using rspec-support 3.0.3
Using rspec-core 3.0.3
Using rspec-expectations 3.0.3
Using rspec-mocks 3.0.3
Using rspec 3.0.0
Using sauce_whisk 0.0.13
Using bundler 1.6.2
Your bundle is updated!
+ rake android
.

Finished in 38.39 seconds (files took 1.52 seconds to load)
1 example, 0 failures
Finished: SUCCESS

Making Sure We Have A Clean Finish

We now have a working job in Jenkins. But we’re not there yet. While the job was runnning you should have seen the Android Emulator open, load the test app, and perform the test actions. Unfortunately, after the job completed, the emulator didn’t close.

Closing the Android Emulator is something that Appium doesn’t handle, so we’ll need to account for this in our Jenkins build configuration. Otherwise, we won’t leave things in a clean state for future test runs.

The simplest way to close the emulator is by issuing a kill command against the name of the process (ensuring that the command always returns true). That way we cover our bases in case there is more than one emulator process running or if we try to kill a process that doesn’t exist. So let’s go ahead and add the kill command to our existing commands under the Build section of our job. For good measure, let’s add it before and after our test execution commands.

To get back to the job configuration screen, click Configure from the main job screen.

killall -9 emulator64-x86 || true

cd /path/to/your/appium/test/code
bundle update
rake android

killall -9 emulator64-x86 || true

Now let’s save the job and build it again. The job will run just like before, but now the emulator will close after the test run completes.

Creating Another Job

Now let’s create a second job to run our tests against iOS.

To save a step, let’s create a copy of our existing job and modify the build commands as needed.

  1. Click the Jenkins logo at the top of the screen (it will take you to the main page)
  2. Click New Item in the top-left corner
  3. Type a name into the Item name input field (e.g., Appium iOS)
  4. Select Copy existing Item
  5. Start to type in the name of the other job in the Copy from input field (e.g., Appium Android)
  6. Select the job from the drop-down as it appears
  7. Click OK

 

This will take us to a configuration screen for the new (copied) job. Let’s scroll down to the Build section and modify the Command input field under Execute Shell.

killall -9 "iPhone Simulator" &> /dev/null || true
killall -9 instruments &> /dev/null || true

cd /path/to/your/appium/test/code
bundle update
rake ios

killall -9 "iPhone Simulator" &> /dev/null || true
killall -9 instruments &> /dev/null || true

Similar to the Android job, we’re using kill to end a process (in this case two processes) and making sure the command returns true if it doesn’t exist. This protects us in the event that the test suite doesn’t complete as planned (leaving a simulator around) or if the simulator doesn’t close instruments cleanly (which can happen).

If we save this and build it, then we will see the iPhone Simulator load, launch the app, run the tests, and then close the simulator.

Running Tests On Sauce

We’ve covered running things locally on the CI server, now let’s create a job to run our tests on Sauce.

Let’s create another copy of the Appium Android job and modify the build commands.

Since we’re not going to be running locally, we can remove the kill line. We’ll then specify our Sauce credentials (through environment variables) and update the rake command to specify 'sauce' as a location. When we’re done, our Command window should look like this:

export SAUCE_USERNAME=your-username
export SAUCE_ACCESS_KEY=your-access-key

cd /path/to/your/appium/test/code
bundle update
rake android['sauce']

If we save this and build it, our tests will now run on Sauce Labs. And you can view them as they happen on your Sauce Labs Account Page.

An iOS job would be identical to this, except for the job name (e.g., Appium iOS Sauce) and the rake incantation (which would be rake ios['sauce'].

Outro

Now that we have our Appium tests wired up for automatic execution, we’re now able to configure them to run based on various triggers (e.g., other CI jobs, a schedule, etc.). Find what works for you and your development team’s workflow, and make it happen.

Read:  Chapter 1 Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 | Chapter 7 | Chapter 8

About Dave Haeffner: Dave is a recent Appium convert and the author of Elemental Selenium (a free, once weekly Selenium tip newsletter that is read by thousands of testing professionals) as well as The Selenium Guidebook (a step-by-step guide on how to use Selenium Successfully). He is also the creator and maintainer of ChemistryKit (an open-source Selenium framework). He has helped numerous companies successfully implement automated acceptance testing; including The Motley Fool, ManTech International, Sittercity, and Animoto. He is a founder and co-organizer of the Selenium Hangout and has spoken at numerous conferences and meetups about acceptance testing.

Follow Dave on Twitter – @tourdedave

Announcing CircleCI Integration on Sauce Labs

August 11th, 2014 by Bill McGee

Last week our friends at CircleCI showed us how to securely run cross-browser front-end tests on the Sauce Labs cloud using their hosted Continuous Integration service. We’ve long been advocates of good continuous integration practices and have developed a few plugins for some of the more common CI servers out there. We’re super excited to add CircleCI to our list and even more excited about how easy it is to get it going!

Continuous Integration in the Cloud

Continuous Integration, if you don’t already know, is the process of building your app frequently from a shared source code repository and running tests to make sure everything works. If your tests don’t pass and the build is not successful, the code that was checked in since the last good build is where the defects were introduced, and so problems are much easier to find and fix quickly.

Maintaining a local CI server can be a hassle. Anyone who’s spent any considerable time configuring Jenkins jobs with all it’s various plugins and tasks can tell you all about it. CircleCI, on the other hand, integrates directly with GitHub and can actually *infer* necessary settings directly from your code (if you’re following good development practices for that language and environment) and so many projects just magically build themselves on CircleCI without any additional configuration on your part. It’s like three clicks from zero to CI. Pretty sweet! If you do need to tweak or customize any settings, you can easily do so by describing those settings in a circle.yml file placed in your repo.

Running Tests on Sauce Labs Browsers

Sauce Labs is the world’s largest cross-browser client cloud. We host over 375 different configurations of operating systems and browsers so you can ensure that your app works on all the specific platforms and versions you need to support. These days that’s an ever-growing list! So it makes sense to run these tests with your continuous integration process so you know things work across the board and you don’t end up spending a bunch of time and trouble trying to hunt down bugs that were introduced much earlier in the development cycle.

Now, if your build deploys your code to a publicly accessible environment, CircleCI will simply execute your Selenium tests and you probably won’t need to configure anything, since Sauce Labs browsers will be able connect to that environment over the public network. However, if you want CircleCI to execute your tests locally in it’s build containers, you’ll need to use Sauce Connect.

Sauce Connect is a secure tunneling utility which allows you to execute tests behind firewalls via an encrypted connection between Sauce Labs and your testing environment. When you run Sauce Connect yourself, you typically do it from a command line or shell script and supply your Sauce Labs account credentials as parameters. With a CircleCI build, you’ll need to set it up in the circle.yml file so it can be launched as part of the build process and those tests can run inside the local container.

All that’s really involved here is telling the build task where to find Sauce Connect and how to start it up with your account credentials.

The first part is downloading and unpacking the Sauce Connect file, which you add as a custom dependency entry in your circle.yml:

	dependencies:
	  post:
		   - wget https://saucelabs.com/downloads/sc-latest-linux.tar.gz
		   - tar -xzf sc-latest-linux.tar.gz

The second part is to add your credentials, launch the tunnel, and check that it’s running before kicking off the tests. You’ll put these lines in the `test` section of circle.yml:

test:
     override:
        - ./bin/sc -u $SAUCE_USERNAME -k $SAUCE_ACCESS_KEY -f ~/sc_ready:
            background: true
            pwd: sc-*-linux
        # Wait for tunnel to be ready
        - while [ ! -e ~/sc_ready ]; do sleep 1; done

That’s all there is to it. You can find out the details here and see a full example on GitHub. And CircleCI has a nice little utility to help you add your credentials as environment variables so that they are not visible as plain text in the repo.

With CircleCI tackling all the necessary work involved in supporting your continuous integration process and Sauce Labs hosting the world’s most extensive cross-browser client cloud, you can be free of the costs and hassles of managing all these systems and grids and get back to focusing on the business of making great software.

Michael Sage, Principal Technology Evanglist, Sauce Labs

Michael Sage is a Principal Technology Evangelist at Sauce Labs. He helps software teams develop, deliver, and care for great apps. He’s lived through two or three technology revolutions and expects a few more to come, and finds the prospect incredibly exciting. A native of Philadelphia, he’s made San Francisco his home for over 25 years, but still can’t find a good hoagie there.

Appium Bootcamp – Chapter 2: The Console

July 23rd, 2014 by Bill McGee

appium_logoThis is the second post in a series called Appium Bootcamp by noted Selenium expert Dave Haeffner

Read:  Chapter 1 Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 | Chapter 7 | Chapter 8

Dave recently immersed himself in the open source Appium project and collaborated with leading Appium contributor Matthew Edwards to bring us this material. Appium Bootcamp is for those who are brand new to mobile test automation with Appium. No familiarity with Selenium is required, although it may be useful. This is the second of eight posts; a new post will be released each week.

Configuring Appium

In order to get Appium up and running there are a few additional things we’ll need to take care of.

If you haven’t already done so, install Ruby and setup the necessary Appium client libraries (a.k.a. “gems”). You can read a write-up on how to do that here.

Installing Necessary Libraries

Assuming you’ve already installed Ruby and need some extra help installing the gems, here’s what you to do.

  1. Install the gems from the command-line with gem install appium_console
  2. Once it completes, run gem list | grep appium

You should see the following listed (your version numbers may vary):

appium_console (1.0.1)
appium_lib (4.0.0)

Now you have all of the necessary gems installed on your system to follow along.

An Appium Gems Primer

appium_lib is the gem for the Appium Ruby client bindings. It is what we’ll use to write and run our tests against Appium. It was installed as a dependency to appium_console.

appium_console is where we’ll focus most of our attention in the remainder of this and the next post. It is an interactive prompt that enables us to send commands to Appium in real-time and receive a response. This is also known as a record-eval-print loop (REPL).

Now that we have our libraries setup, we’ll want to grab a copy of our app to test against.

Sample Apps

Don’t have a test app? Don’t sweat it. There are pre-compiled test apps available to kick the tires with. You can grab the iOS app here and the Android app here. If you’re using the iOS app, you’ll want to make sure to unzip the file before using it with Appium.

If you want the latest and greatest version of the app, you can compile it from source. You can find instructions on how to do that for iOS here and Android here.

Just make sure to put your test app in a known location, because you’ll need to reference the path to it next.

App Configuration

When it comes to configuring your app to run on Appium there are a lot of similarities to Selenium — namelythe use of Capabilities (e.g., “caps” for short).

You can specify the necessary configurations of your app through caps by storing them in a file called appium.txt.

Here’s what appium.txt looks like for the iOS test app to run in an iPhone simulator:

[caps]
platformName = "ios"
app = "/path/to/UICatalog.app.zip"
deviceName = "iPhone Simulator"

And here’s what appium.txt looks like for Android:

[caps]
platformName = "android"
app = "/path/to/api.apk"
deviceName = "Android"
avd = "training"

For Android, note the use of both avd. The "training" value is for the Android Virtual Device that we configured in the previous post. This is necessary for Appium to auto-launch the emulator and connect to it. This type of configuration is not necessary for iOS.

For a full list of available caps, read this.

Go ahead and create an appium.txt with the caps for your app.

Launching The Console

Now that we have a test app on our system and configured it to run in Appium, let’s fire up the Appium Console.

First we’ll need to start the Appium server. So let’s head over to the Appium GUI and launch it. It doesn’t matter which radio button is selected (e.g., Android or Apple). Just click the Launch button in the top right-hand corner of the window. After clicking it, you should see some debug information in the center console. Assuming there are no errors or exceptions, it should be up ready to receive a session.

After that, go back to your terminal window and run arc (from the same directory asappium.txt). This is the execution command for the Appium Ruby Console. It will take the caps from appium.txt and launch the app by connecting it to the Appium server. When it’s done you will have an emulator window of your app that you can interact with as well as an interactive command-prompt for Appium.

Outro

Now that we have our test app up and running, it’s time to interrogate our app and learn how to interact with it.

Read:  Chapter 1 Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 | Chapter 7 | Chapter 8

About Dave Haeffner: Dave is a recent Appium convert and the author of Elemental Selenium (a free, once weekly Selenium tip newsletter that is read by thousands of testing professionals) as well as The Selenium Guidebook (a step-by-step guide on how to use Selenium Successfully). He is also the creator and maintainer of ChemistryKit (an open-source Selenium framework). He has helped numerous companies successfully implement automated acceptance testing; including The Motley Fool, ManTech International, Sittercity, and Animoto. He is a founder and co-organizer of the Selenium Hangout and has spoken at numerous conferences and meetups about acceptance testing.

Follow Dave on Twitter – @tourdedave

Appium Bootcamp – Chapter 1: Get Started With Appium

July 16th, 2014 by Bill McGee

appium_logoThis is the first post in a series called Appium Bootcamp by noted Selenium expert Dave Haeffner.

Read:  Chapter 1 Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 | Chapter 7 | Chapter 8

Dave recently immersed himself in the open source Appium project and collaborated with leading Appium contributor Matthew Edwards to bring us this material. Appium Bootcamp is for those who are brand new to mobile test automation with Appium. No familiarity with Selenium is required, although it may be useful. This is the first of eight posts; a new post will be released each week. 

Before You Get Started

Appium is built to test mobile apps of all kinds (native, hybrid, and mobile web), has client libraries written in every popular programming language, it’s open source, works on every prominent operating system, and best of all — it works for iOS and Android.

But before you jump in with both feet, know that there is a bit of setup in order to get things up and running on your local machine.

A brief Appium primer

Appium is architected similarly to Selenium — there is a server which receives commands and executes them on a desired node. But instead of a desktop browser, the desired node is running a mobile app on a mobile device (which can be either a simulator, an emulator, or a physical device).

So in order for Appium to work, we will need to install the dependent libraries for each device we care about.

Initial Setup

Testing an iOS app? Here’s what you’ll need:

+ Install Java (version 7 of the JDK or higher)
+ Install Xcode
+ Install Xcode Command-line Build Tools

For more info on supported Xcode versions, read this.

Testing an Android app? Here’s what you’ll need:

+ Install Java (version 7 of the JDK or higher)
+ Install the Android SDK (version 17 or higher)
+ Install the necessary packages for your Android platform version in the Android SDK Manager
+ Configure an Android Virtual Device (AVD) that mimics the device you want to test against

For more info on setting up the Android SDK and configuring an AVD, read this.

Next, you’ll need to install Appium. Luckily, there’s a handy binary for it Appium.app for OSX and Appium.exe for Windows. This binary also happens to be a GUI wrapper for Appium.

Alternatively, if you want the absolute latest version of Appium and aren’t afraid to get your hands dirty, then you can install Appium from source and run it from the command line.

But if you’re new to mobile testing, then the one-click installer is a better place to start.

An Appium GUI primer

The Appium GUI is a one-click installer for the Appium server that enables easy configuration of your app and Appium.

Aside from the easy install, it adds a key piece of functionality — an inspector. The inspector enables a host of functionality, most notably:

+ Shows you all of the elements in your app
+ Enables you to record and playback user actions

inspector_android

While the inspector works well for iOS, there are some problem areas with it in Android on Appium at the moment. To that end, the Appium team encourages the use of uiautomatorviewer (which is an inspector tool provided by Google that provides similar functionality to the Appium inspector tool). For more info on how to set that up, read this.

uiautomatorviewer

More on inspectors and how to use them in a later post.

It’s worth noting that while we can configure our app within the Appium GUI, it’s not necessary since we will be able to do it more flexibly in code. More on that in the next post.

Making Sure Appium Is Setup

After you have your Appium one-click installer up and running, you can verify your setup by using it’s Doctor functionality. It is the button on the left of the `Launch` button. It is the one that looks like a doctor’s stethoscope.

Click on that, and it should output information in the center console window of the Appium GUI.

appium_doctor

If you don’t see anything outputted, refer to this open issue.

What About A Programming Language?

Before you do a victory lap, you’ll also want to have chosen a programming language to write your tests in, installed said programming language, and installed it’s client bindings for Appium.

Currently, Appium has client bindings for JavaJavaScriptObjective C.NETPHPPython, and Ruby.

The examples in this series will be written in Ruby. You can use version 1.9.3 or later, but it’s advisable to use the latest stable version. For instructions on installing Ruby and the necessary client libraries (a.k.a. “gems”), read this.

Outro

Now that you have Appium setup with all of it’s requisite dependencies, along with a programming language and Appium client bindings, we’re ready to load up a test app and step through it.

Read:  Chapter 1 Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 | Chapter 7 | Chapter 8

About Dave Haeffner: Dave is a recent Appium convert and the author of Elemental Selenium (a free, once weekly Selenium tip newsletter that is read by thousands of testing professionals) as well as The Selenium Guidebook (a step-by-step guide on how to use Selenium Successfully). He is also the creator and maintainer of ChemistryKit (an open-source Selenium framework). He has helped numerous companies successfully implement automated acceptance testing; including The Motley Fool, ManTech International, Sittercity, and Animoto. He is a founder and co-organizer of the Selenium Hangout and has spoken at numerous conferences and meetups about acceptance testing.

Follow Dave on Twitter – @tourdedave