Appium Bootcamp – Chapter 7: Automate Your Test Runs

Sauce AI for Test Authoring: Move from intent to performance in minutes.|xBack to ResourcesBlogPosted<

June 08, 2026 · 9 min read · Tool Comparison

Sauce AI for Test Authoring: Move from intent to performance in minutes.

Blog

Posted August 12, 2014

Appium Bootcamp – Chapter 7: Automate Your Test Runs

[UPDATE- November 2019]You can find the newest Get Started with Appium white papers here:Get Started with Appium- Java and Get Started with Appium- Ruby

This is the 7th situation in a series called Appium Bootcamp by noted Selenium expert Dave Haeffner.

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

To make our test as utilitarian as potential, we & # x27; ll require to automate when they get run. To do that, we & # x27; ll use a Continuous Integration (CI) Server.

A Continuous Integration Server Primer

A Continous Integration server (a.k.a. CI) is creditworthy for merging codification that is actively being developed into a key place (e.g., & quot; trunk & quot; or & quot; master & quot;) often (e.g., several times a day, or on every code commit) to discover subject early so they can be addressed quickly -- all for the sake of unloose act software in a timely mode.

With CI, we can automate our test runs so they can hap as component of the development workflow. The Leo & # x27; s share of tests that are typically run on a CI Server are unit (and potentially integration) tests. But we can rattling easily add in our automated mobile tests.

There are numerous CI Servers available for use today. Let & # x27; s pick one and tread through an example.

A CI Example

Jenkinsis a fully functional, widely adopted, and open-source CI server. It & # x27; s a outstanding candidate for us to tread through.

Let & # x27; s beginning by position it up on the like machine as our Appium Server. Keep in mind that this isn & # x27; t the & quot; proper & quot; way to go about this -- it & # x27; s simply good for this example. To do it flop, the Jenkins host (e.g., master node) would live on a machine of its own.

Quick Setup

A simple way to get started is to catch the latest Jenkins war file. You can grab it fromthe 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 capable to use Jenkins by see [http: //localhost:8080/] (http: //localhost:8080/) in your browser.

Running Tests Locally

After laden Jenkins in the browser, we & # x27; ll create a Job and configure it to run our Appium test. Let & # x27; s start with the Android tests firstly.

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

This will load a configuration screen for the Jenkins Job.

Scroll downwardly until you make the Build section (near the fundament of the page)
Click Add build measure
Select Execute shell
Input the following into the Command remark box

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

In this set of commands we are narrate Jenkins to change directory to our trial codification, get sure we have the necessary library, and then launch the Android tests.

SUSA automates exploratory testing with persona-driven behavior, catching bugs that scripted automation misses.

Click Saveat the bottom of the page, make certain your Appium Server is running (if not, load up the Appium GUI and clickLaunch), and clickBuild Nowon the left-hand side of the Jenkins Job screen.

Once it & # x27; s running, you can click on the job under Build History, and so click Console Output (from the left-hand panel). In it, you should see something like to this:

1
Started by user anon.
2
Building in workspace /Users/tourdedave/.jenkins/jobs/Appium Android/workspace
3
[workspace] $ /bin/sh -xe /var/folders/yt/h7v9k6px7jl68q81c9sqrd9h0000gn/T/hudson6140596697737249507.sh
4
+ cd /Users/tourdedave/Dropbox/_dev/appium/appium-getting-started/code-examples/7/1
5
+ bundle update
6
Fetching gem metadata from https: //rubygems.org/ ...........
7
Fetching additional metadata from https: //rubygems.org/ ..
8
Resolving dependencies ...
9
Using rake 10.3.2
10
Using awesome_print 1.2.0
11
Using json 1.8.1
12
Using mini_portile 0.6.0
13
Using nokogiri 1.6.3.1
14
Using ffi 1.9.3
15
Using childprocess 0.5.3
16
Using multi_json 1.10.1
17
Using rubyzip 1.1.6
18
Using websocket 1.0.7
19
Using selenium-webdriver 2.42.0
20
Using blankslate 2.1.2.4
21
Using parslet 1.5.0
22
Using toml 0.1.1
23
Using appium_lib 4.0.0
24
Using alliance 0.5.1
25
Using coderay 1.1.0
26
Using method_source 0.8.2
27
Using slop 3.6.0
28
Using pry 0.9.12.6
29
Using numerizer 0.1.1
30
Using chronic_duration 0.10.5
31
Using spec 5.3.4
32
Using appium_console 1.0.1
33
Using diff-lcs 1.2.5
34
Using mime-types 1.25.1
35
Using rdoc 4.1.1
36
Using rest-client 1.6.8
37
Using rspec-support 3.0.3
38
Using rspec-core 3.0.3
39
Using rspec-expectations 3.0.3
40
Using rspec-mocks 3.0.3
41
Using rspec 3.0.0
42
Using sauce_whisk 0.0.13
43
Using bundler 1.6.2
44
Your bundle is updated!
45
+ rake andorid
46
.
47
48
Finished in 38.39 seconds (file took 1.52 minute to burden)
49
1 example, 0 failures
50
Finished: SUCCESS

Making Sure We Have A Clean Finish

We now hold a working job in Jenkins. But we & # x27; re not there yet. While the job was runnning you should have seen the Android Emulator open, load the tryout app, and do the test actions. Unfortunately, after the job dispatch, the emulator didn & # x27; t tight.

Closing the Android Emulator is something that Appium doesn & # x27; t handle, so we & # x27; ll need to account for this in our Jenkins build configuration. Otherwise, we won & # x27; t leave thing in a light state for future test runs.

The mere way to close the emulator is by issuing akillcommand against the name of the procedure (assure that the command always returnstrue). That way we cover our foundation in case there is more than one emulator process running or if we try to kill a summons that doesn & # x27; t survive. So let & # x27; s go forward and add thekillbidding to our existing commands under theBuildsubdivision of our job. For good quantity, let & # x27; s add it before and after our tryout execution command.

To get backwards to the job configuration screen, clinkConfigurefrom the primary job screen.

killall -9 emulator64-x86 || true

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

killall -9 emulator64-x86 || true

Now let & # x27; s save the job and establish 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 & # x27; s create a 2nd job to run our exam against iOS.

To save a step, let & # x27; s create a copy of our survive job and modify the build commands as needed.

Click the Jenkins logotype at the top of the blind (it will direct you to the main page)
Click New Itemin the top-left corner
Type a name into theItem namestimulant battlefield (e.g.,Appium iOS)
Select Copy existing Item
Start to type in the name of the former job in theCopy frominput field (e.g.,Appium Android)
Select the job from the drop-down as it appears
Click OK

This will direct us to a configuration screen for the new (copied) job. Let & # x27; s scroll down to theBuildsection and modify theCommandinput field underExecute Shell.

killall -9 & quot; iPhone Simulator & quot; & amp; & gt; /dev/null || true
killall -9 instruments & amp; & gt; /dev/null || true

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

killall -9 & quot; iPhone Simulator & quot; & amp; & gt; /dev/null || true
killall -9 cat's-paw & amp; & gt; /dev/null || true

Similar to the Android job, we & # x27; re usingkillto end a procedure (in this case two processes) and do certain the command returnstrueif it doesn & # x27; t live. This protect us in the event that the test rooms doesn & # x27; t accomplished as design (leave a simulator around) or if the simulator doesn & # x27; t nigh instruments flawlessly (which can happen).

If we salvage this and build it, then we will see the iPhone Simulator load, launch the app, run the trial, and then fold the simulator.

Running Tests On Sauce

We & # x27; ve covered running things topically on the CI host, now let & # x27; s create a job to run our test on Sauce.

Let & # x27; s create another copy of theAppium Androidjob and modify the build commands.

Since we & # x27; re not proceed to be running topically, we can withdraw thekillline. We & # x27; ll so specify our Sauce credentials (through surround variables) and update therakecommand to specify& # x27; sauce & # x27;as a location. When we & # x27; re done, ourCommandwindow should appear like this:

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

cd /path/to/your/appium/test/code
bundle update
rake android [& # x27; sauce & # x27;]

If we save this and build it, our trial 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 rakeconjuration (which would berake ios [& # x27; sauce & # x27;].

Outro

Now that we have our Appium tests wired up for automatic execution, we & # x27; 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 & # x27; s workflow, and create it happen.

About Dave Haeffner: Dave is a late Appium convert and the author of Elemental Selenium (a free, once weekly Selenium tip newssheet that is read by thousands of examine master) as well as The Selenium Guidebook (a step-by-step guide on how to use Selenium Successfully). He is also the creator and maintainer ofChemistryKit(an open-source Selenium model). He has helped numerous company successfully implement automated acceptance testing; include The Motley Fool, ManTech International, Sittercity, and Animoto. He is a founder and co-organizer of theSelenium Hangoutand has spoken at legion league and meetups about credence examination.

Follow Dave on Twitter -@ tourdedave

Continue the reading the former chapter:

Appium Bootcamp- Chapter 1: Get Started with Appium

Appium Bootcamp - Chapter 2: The Console

Appium Bootcamp - Chapter 3: Interrogating Your App

Appium Bootcamp - Chapter 4: Your First Test

Appium Bootcamp - Chapter 5: Writing and Refactoring Your Tests

Appium Bootcamp - Chapter 6: Run Your Tests

Appium Bootcamp - Chapter 8: Additional Information + Resources