Android Automated Testing Topical Guidelines

Document Version 0.0.2

This document is intended to explain in a more detailed manner the aspects outlined during the presentation.

Android Automated Testing Topical Guidelines

___________________________________
Contents
1. Introduction to Android. Environment Setup and Configuration ..................................................3 App Components.................................................................................................................................4 Activities................................................................................................................................................4 Services................................................................................................................................................ 4 Content providers................................................................................................................................4 Broadcast receivers............................................................................................................................5 Environment Setup and Configuration.............................................................................................5 . Building !our first Application............................................................................................................7 Android "ro#ects..................................................................................................................................8 $. Introduction to Automated Testing. Android Testing %undamentals..........................................12 Test Projects.......................................................................................................................................13 &'nit................................................................................................................................................ 14 Instrumentation..............................................................................................................................14 Test case classes..........................................................................................................................15 (unning Tests.................................................................................................................................... 17 Seeing Test (esults.......................................................................................................................... 18 )on*e! and mon*e!runner.............................................................................................................18 +or*ing ,ith "ac*age names.........................................................................................................18 +hat to Test....................................................................................................................................... 19 Testing from Eclipse with ADT...............................................................................................................19 Creating a Test "ro#ect..................................................................................................................... 19 Creating a Test "ac*age..................................................................................................................20 -. Android Activit! Testing.................................................................................................................... 22 .. Android Service Testing................................................................................................................... 27

1. Introduction to Android. Environment Setup and Con iguration

___________________________________
Android is an operating system based on the Linux Kernel and designed primarily for touchscreen mobile devices such as smart phones and tablets. Android was unveiled in 2 ! along with the founding of the "pen #andset Alliance$ a consortium of hardware% software% and telecommunication companies devoted to advancing open standards for mobile devices. The user interface of Android is based on direct manipulation% using touch inputs that loosely correspond to real& world actions% li'e swiping% tapping% pinching and reverse pinching to manipulate on&screen ob(ects. )nternal hardware such as accelerometers% gyroscopes and proximity sensors are used by some applications to respond to additional user actions% for example ad(usting the screen from portrait to landscape depending on how the device is oriented. Android source *oogle the code Apache Android written +ava is open and releases source under the License. apps are in the

programming language. The Android ,DK tools compile your code-along with any data and resource filesinto an A.K$ an Android pac'age% which is an archive file with an /.ap'0 suffix. "ne A.K file contains all the contents of an Android app and is the file that Android&powered devices use to install the app.

App Components

App components are the essential building bloc's of an Android app. Each component is a different point

through which the system can enter your app. 1ot all components are actual entry points for the user and some depend on each other% but each one exists as its own entity and plays a specific role-each one is a uni2ue building bloc' that helps define your app3s overall behavior. There are four different types of app components. Each type serves a distinct purpose and has a distinct life cycle that defines how the component is created and destroyed. #ere are the four types of app components$
Activities

An activity represents a single screen with a user interface. 4or example% an email app might have one activity that shows a list of new emails% another activity to compose an email% and another activity for reading emails. Although the activities wor' together to form a cohesive user experience in the email app% each one is independent of the others. As such% a different app can start any one of these activities 5if the email app allows it6. 4or example% a camera app can start the activity in the email app that composes new mail% in order for the user to share a picture. An activity is implemented as a subclass of Activity and you can learn more about it in the Activities developer guide.
Services

A service is a component that runs in the bac'ground to perform long&running operations or to perform wor' for remote processes. A service does not provide a user interface. 4or example% a service might play music in the bac'ground while the user is in a different app% or it might fetch data over the networ' without bloc'ing user interaction with an activity. Another component% such as an activity% can start the service and let it run or bind to it in order to interact with it. A service is implemented as a subclass of ,ervice and you can learn more about it in the ,ervices developer guide.
Content providers

A content provider manages a shared set of app data. 7ou can store the data in the file system% a ,8Lite database% on the web% or any other persistent storage location your app can access. Through the content provider% other apps can 2uery or even modify the data 5if the content provider allows it6. 4or example% the Android system provides a content provider that manages the user3s contact information. As such% any app with the proper permissions can 2uery part of the content provider 5such as 9ontacts9ontract.Data6 to read and write information about a particular person. 9ontent providers are also useful for reading and writing data that is private to your app and not shared. 4or example% the 1ote .ad sample app uses a content provider to save notes. A content provider is implemented as a subclass of 9ontent.rovider and must implement a standard set of A.)s that enable other apps to perform transactions. 4or more information% see the 9ontent .roviders developer guide.
!roadcast receivers

A broadcast receiver is a component that responds to system&wide broadcast announcements. :any broadcasts originate from the system-for example% a broadcast announcing that the screen has turned off% the battery is low% or a picture was captured. Apps can also initiate broadcasts-for example% to let other apps 'now that some data has been downloaded to the device and is available for them to use. Although

broadcast receivers don3t display a user interface% they may create a status bar notification to alert the user when a broadcast event occurs. :ore commonly% though% a broadcast receiver is (ust a ;gateway; to other components and is intended to do a very minimal amount of wor'. 4or instance% it might initiate a service to perform some wor' based on the event. A broadcast receiver is implemented as a subclass of <roadcast=eceiver and each broadcast is delivered as an )ntent ob(ect. 4or more information% see the <roadcast=eceiver class. Before the Android system can start an app component, the system must know that the component exists by reading the app's Android:anifest.xml file (the "manifest" file). our app must declare all its components in this file, which must be at the root of the app pro!ect directory. The manifest does a number of things in addition to declaring the app3s components% such as$ )dentify any user permissions the app re2uires% such as )nternet access or read&access to the user3s contacts. Declare the minimum A.) Level re2uired by the app% based on which A.)s the app uses. Declare hardware and software features used or re2uired by the app% such as a camera% <luetooth services% or a multitouch screen. A.) libraries the app needs to be lin'ed against 5other than the Android framewor' A.)s6% such as the *oogle :aps library. And more

Environment Setup and Con iguration

The Android Developer Tools 5ADT6 plugin for Eclipse provides a professional&grade development environment for building Android apps. )t3s a full +ava )DE with advanced features to help you build% test% debug% and pac'age your Android apps. The ADT <undle provides everything you need to start developing apps% including a version of the Eclipse )DE with built&in A"# (Android "e$eloper #ools) to streamline your Android app development.

Installing t"e Eclipse #lugin Android offers a custom plugin for the Eclipse )DE% called Android Development Tools 5ADT6. This plugin provides a powerful% integrates environment in which to develop Android apps. )t extends the capabilities of Eclipse to let you 2uic'ly set up new Android pro(ects% build app >)% debug your app% and export signed 5or unsigned6 app pac'ages 5A.K6 for distribution. To install Eclipse please see the following lin' $ http$??www.eclipse.org?downloads? Do$nload t"e ADT #lugin @. ,tart Eclipse% then select %elp & 'nstall (ew )oftware. 2. 9lic' Add% in the top&right corner. A. )n the Add =epository dialog that appears% enter /ADT .lugin0 for the 1ame and the following >=L for the Location$ https$??dl&ssl.google.com?android?eclipse? B. 9lic' *+. )f you have trouble ac2uiring the plugin% try using /http0 in the Location >=L% instead of /https0 5https is preferred for security reasons6. C. )n the Available ,oftware dialog% select the chec'box next to Developer Tools and clic' (ext. D. )n the next window% you3ll see a list of tools to be downloaded. 9lic' (ext. !. =ead and accept the license agreement then clic' ,inish. )f you get a security warning saying that the authenticity or validity of the software can3t be established% clic'

*+. E. Fhen the installation is complete% restart Eclipse. Con igure t"e ADT #lugin "nce Eclipse restarts% you must specify the location of your Android ,DK directory. @. )n the /Felcome to Android Development0 window that appears% select -se existing )"+s. 2. <rowse and select the location of the Android ,DK directory you recently downloaded and unpac'ed. A. 9lic' (ext Adding #lat orms and #ac%ages The Android ,DK separates tools% platforms% and other components into pac'ages you can download using the Android ,DK :anager. The original ,DK pac'age you3ve downloaded includes only the ,DK Tools. To develop an Android app% you also need to download at least one Android platform and the latest ,DK .latform&tools. @. Launch the ,DK :anager$ )f you3ve used the Findows installer to install the ,DK tools% you should already have the Android ,DK :anager open. "therwise% you can launch the Android ,DK :anager in one of the following ways$ "n Findows% double&clic' the SDK Manager.exe file at the root of the Android ,DK directory. "n :ac or Linux% open a terminal and navigate to the tools/ directory in the Android ,DK% then execute android sdk. 2. The ,DK :anager shows all the ,DK pac'ages available for you to add to your Android ,DK. As a minimum configuration for your ,DK% we recommend you install the following$ The latest Tools pac'ages 5chec' the #ools folder6. The latest version of Android 5chec' the first Android folder6. The Android ,upport Library 5open the .xtras folder and chec' Android )upport /ibrary6. "nce you3ve chosen your pac'ages% clic' 'nstall. The Android ,DK :anager installs the selected pac'ages into your Android ,DK environment.

4or more information about )nstalling and configuring you )DE please visit$ http$??developer.android.com?sd'?installing?installing&adt.htmlGDownload

2. !uilding &our irst Application

)n order to create a new Android .ro(ect we must go to ,ile01(ew01Android Application 2ro!ect.

The next step is to choose a name for your first Activity and its corresponding layout.

Android #ro'ects
Android pro(ects are the pro(ects that eventually get built into an .ap' file that you install onto a device. They contain things such as application source code and resource files. ,ome are generated for you by default% while others should be created if re2uired. The following directories and files comprise an Android pro(ect$ src? 9ontains your stub Activity file% which is stored at src/your/package/namespace/ActivityName.(ava. All other source code files 5such as .(ava or .aidl files6 go here as well. bin? "utput directory of the build. This is where you can find the final .ap' file and other compiled resources. (ni? 9ontains native code sources developed using the Android 1DK. 4or more information% see the Android 1DK documentation. gen? 9ontains the +ava files generated by ADT% such as your =.(ava file and interfaces created from A)DL files.

assets? This is empty. 7ou can use it to store raw asset files. 4iles that you save here are compiled into an .ap' file as&is% and the original filename is preserved. 7ou can navigate this directory in the same way as a typical file system using >=)s and read files as a stream of bytes using the Asset:anager. 4or example% this is a good location for textures and game data. res? 9ontains application resources% such as drawable files% layout files% and string values. ,ee Application =esources for more information. anim? 4or H:L files that are compiled into animation ob(ects. ,ee the Animation resource type. color? 4or H:L files that describe colors. ,ee the 9olor Ialues resource type. drawable? 4or bitmap files 5.1*% +.E*% or *)46% J&.atch image files% and H:L files that describe Drawable shapes or Drawable ob(ects that contain multiple states 5normal% pressed% or focused6. ,ee the Drawable resource type. layout? H:L files that are compiled into screen layouts 5or part of a screen6. ,ee the Layout resource type. menu? 4or H:L files that define application menus. ,ee the :enus resource type. raw? 4or arbitrary raw asset files. ,aving asset files here instead of in the assets? directory only differs in the way that you access them. These files are processed by aapt and must be referenced from the application using a resource identifier in the = class. 4or example% this is a good place for media% such as :.A or "gg files. values? 4or H:L files that are compiled into many 'inds of resource. >nli'e other resources in the res? directory% resources written to H:L files in this folder are not referenced by the file name. )nstead% the H:L element type controls how the resources is defined within them are placed into the = class. xml? 4or miscellaneous H:L files that configure application components. 4or example% an H:L file that defines a .reference,creen% AppFidget.rovider)nfo% or ,earchability :etadata. ,ee Application =esources for more information about configuring these application components. libs? 9ontains private libraries. Android:anifest.xml The control file that describes the nature of the application and each of its components. 4or instance% it describes$ certain 2ualities about the activities% services% intent receivers% and content providersK what permissions are re2uestedK what external libraries are neededK what device features are re2uired% what A.) Levels are supported or re2uiredK and others. ,ee the Android:anifest.xml documentation for more information pro(ect.properties This file contains pro(ect settings% such as the build target. This file is integral to the pro(ect% so maintain it in a source revision control system. To edit pro(ect properties in Eclipse% right&clic' the pro(ect folder and select 2roperties. local.properties 9ustomiLable computer&specific properties for the build system. )f you use Ant to build the pro(ect% this contains the path to the ,DK installation. <ecause the content of the file is specific to the local installation of the ,DK% the local.properties should not be maintained in a source revision control system. )f you use Eclipse% this file is not used. ant.properties 9ustomiLable properties for the build system. 7ou can edit this file to override default build settings used by Ant and also provide the location of your 'eystore and 'ey alias so that the build tools can

sign your application when building in release mode. This file is integral to the pro(ect% so maintain it in a source revision control system. )f you use Eclipse% this file is not used. build.xml The Ant build file for your pro(ect. This is only applicable for pro(ects that you build with Ant.
App (esources

7ou should always externaliLe resources such as images and strings from your application code% so that you can maintain them independently. ExternaliLing your resources also allows you to provide alternative resources that support specific device configurations such as different languages or screen siLes% which becomes increasingly important as more Android&powered devices become available with different configurations. )n order to provide compatibility with different configurations% you must organiLe resources in your pro(ect3s res/ directory% using various sub&directories that group resources by type and configuration. 4or any type of resource% you can specify default and multiple alternative resources for your application$ Default resources are those that should be used regardless of the device configuration or when there are no alternative resources that match the current configuration. Alternative resources are those that you3ve designed for use with a specific configuration. To specify that a group of resources are for a specific configuration% append an appropriate configuration 2ualifier to the directory name.

Android )ani est

)t is an important part of an Android pro(ect as it is the first place where an application searches for information about the way it should run. )n Android:anifest.xml we have listed the pac'age name% names of all activities% intents and also permissions 5for example% in order to use the deviceMs camera or to access the internet% we must declare a specific permission within this file6. Also% in this file it is mentioned the minimum Android A.) needed for running the application.

<?xml version=1.0 encoding=utf-8?> <manifest xmlns:android=http://schemas.android.com/apk/res/android package=com.rinf.mobile.rotemps android:versionCode=1 android:versionName=1.0 > <uses-sdk android:minSdkVersion=8 android:targetSdkVersion=18 /> <application android:allow ackup=true android:icon=@drawable/ic_launcher android:la!el=@string/app_name android:t"eme=@style/App heme > <activit# android:name=com.rinf.mobile.rotemps.!ainActi"ity android:la!el=@string/app_name > <intent-filter> <action android:name=android.intent.action.!A#$ /> <categor# android:name=android.intent.category.%A&$'()* /> </intent-filter> </activit#> </application>

</manifest><$xml version=1.0 encoding=utf+8$> <manifest xmlns:android=http://schemas.android.com/apk/res/android package=com.rinf.mobile.rotemps android:versionCode=1 android:versionName=1.0 > <uses-sdk android:minSdkVersion=8 android:targetSdkVersion=18 /> <application android:allow ackup=true android:icon=@drawable/ic_launcher android:la!el=@string/app_name android:t"eme=@style/App heme > <activit# android:name=com.rinf.mobile.rotemps.!ainActi"ity android:la!el=@string/app_name > <intent-filter> <action android:name=android.intent.action.!A#$ /> <categor# android:name=android.intent.category.%A&$'()* /> </intent-filter> </activit#> </application> </manifest> T"e *a&out We can look at our layout file (activity_first_page.xml) from two perspectives: as Grap ical !ayout ( ere we can actually see all t e "uttons# e$it texts# an$ ot er grap ical o"jects)# or we can see t e actual co$e "e in$ eac element (next to Grap ical !ayout ta" we ave activity %&_first_page.xml ta"). 'ere we can $efine t e position of t e elements# t eir $imensions# t eir "ackgroun$ an$ also t eir la"els (e.g.: t e text $isplaye$ on a "utton).

10

+. Introduction to Automated Testing. Android Testing ,undamentals

___________________________________
-nit Testing
A unit test is a piece of code written by a developer that executes a specific functionality in the code which is tested. The percentage of code which is tested by unit tests is typically called test coverage. A unit test targets a small unit of code% e.g. a method or a class% 5local tests6. >nit tests ensure that code wor's as intended. They are also very helpful to ensure that the code still wor's as intended in case you need to modify code for fixing a bug or extending functionality. #aving a high test coverage of your code allows you to continue developing features without having to perform lots of manual tests.

Android testing
The test follows the flow depicted in the following diagram$

11

Test Structure
Android3s build and test tools assume that test pro(ects are organiLed into a standard structure of tests% test case classes% test pac'ages% and test pro(ects. Android testing is based on +>nit. )n general% a +>nit test is a method whose statements test a part of the application under test. 7ou organiLe test methods into classes called test cases 5or test suites6. Each test is an isolated test of an individual module in the application under test. Each class is a container for related test methods% although it often provides helper methods as well. )n +>nit% you build one or more test source files into a class file. ,imilarly% in Android you use the ,DK3s build tools to build one or more test source files into class files in an Android test pac'age. )n +>nit% you use a test runner to execute test classes. )n Android% you use test tools to load the test pac'age and the application under test% and the tools then execute an Android&specific test runner.
Test Projects

Tests% li'e Android applications% are organiLed into pro(ects. A test pro(ect is a directory or Eclipse pro(ect in which you create the source code% manifest file% and other files for a test pac'age. The Android ,DK contains tools for Eclipse with ADT and for the command line that create and update test pro(ects for you. The tools create the directories you use for source code and resources and the manifest file for the test pac'age. The command&line tools also create the Ant build files you need. 7ou should always use Android tools to create a test pro(ect. Among other benefits% the tools$

Automatically set up your test pac'age to use )nstrumentationTest=unner as the test case runner. 7ou
must use )nstrumentationTest=unner 5or a subclass6 to run +>nit tests. 9reate an appropriate name for the test pac'age. )f the application under test has a pac'age name of com.mydomain.myapp% then the Android tools set the test pac'age name to com.mydomain.myapp.test. This helps you identify their relationship% while preventing conflicts within the system. Automatically create the proper build files% manifest file% and directory structure for the test pro(ect. This helps you to build the test pac'age without having to modify build files and sets up the lin'age between your test pac'age and the application under test. 7ou can create a test pro(ect anywhere in your file system% but the best approach is to add the test pro(ect so that its root directory tests? is at the same level as the src? directory of the main application3s pro(ect. This helps you find the tests associated with an application. 4or example% if your application pro(ec t3s root directory is :y.ro(ect% then you should use the following directory structure$
(yProject) *n$roi$(anifest.xml res) ... (resources for main application) src) ... (source co$e for main application) ... tests) *n$roi$(anifest.xml res) ... (resources for tests) src) ... (source co$e for tests)

12

T"e Testing A#I

The Android testing A.) is based on the +>nit A.) and extended with an instrumentation framewor' and Android&specific testing classes.
.-nit

7ou can use the +>nit Test9ase class to do unit testing on a class that doesn3t call Android A.)s. Test9ase is also the base class for AndroidTest9ase% which you can use to test Android&dependent ob(ects. <esides providing the +>nit framewor'% AndroidTest9ase offers Android&specific setup% teardown% and helper methods. 7ou use the +>nit Assert class to display test results. The assert methods compare values you expect from a test to the actual results and throw an exception if the comparison fails. Android also provides a class of assertions that extend the possible types of comparisons% and another class of assertions for testing the >). These are described in more detail in the section Assertion classes To learn more about +>nit% you can read the documentation on the (unit.org home page. 1ote that the Android testing A.) supports +>nit A code style% but not +>nit B. Also% you must use Android3s instrumented test runner )nstrumentationTest=unner to run your test case classes. This test runner is described in the section =unning Tests.
Instrumentation

Android instrumentation is a set of control methods or ;hoo's; in the Android system. These hoo's control an Android component independently of its normal lifecycle. They also control how Android loads applications. 1ormally% an Android component runs in a lifecycle determined by the system. 4or example% an Activity ob(ect3s lifecycle starts when the Activity is activated by an )ntent. The ob(ect3s on9reate56 method is called% followed by on=esume56. Fhen the user starts another application% the on.ause56 method is called. )f the Activity code calls the finish56 method% the onDestroy56 method is called. The Android framewor' A.) does not provide a way for your code to invo'e these callbac' methods directly% but you can do so using instrumentation. Also% the system runs all the components of an application into the same process. 7ou can allow some components% such as content providers% to run in a separate process% but you can3t force an application to run in the same process as another application that is already running. Fith Android instrumentation% though% you can invo'e callbac' methods in your test code. This allows you to run through the lifecycle of a component step by step% as if you were debugging the component. The following test code snippet demonstrates how to use this to test that an Activity saves and restores its state$ )) +tart t e main activity of t e application un$er test m*ctivity , get*ctivity())) Get a an$le to t e *ctivity o"ject.s main /0 wi$get# a +pinner m+pinner,(+pinner)m*ctivity.fin$1iew2y0$(com.an$roi$.example.spinner.3.i$.+pinner4%))) +et t e +pinner to a known position m*ctivity.set+pinnerPosition(T5+T_+T*T5_65+T37&_P7+0T078))) +top t e activity 9 T e on6estroy() met o$ s oul$ save t e state of t e +pinner

13

m*ctivity.finis ())) 3e9start t e *ctivity 9 t e on3esume() met o$ s oul$ restore t e state of t e +pinner m*ctivity , get*ctivity())) Get t e +pinner.s current position int currentPosition , m*ctivity.get+pinnerPosition())) *ssert t at t e current position is t e same as t e starting position assert5:uals(T5+T_+T*T5_65+T37&_P7+0T078# currentPosition)The 'ey method used here is getActivity56% which is a part of the instrumentation A.). The Activity under test is not started until you call this method. 7ou can set up the test fixture in advance% and then call this method to start the Activity. Also% instrumentation can load both a test pac'age and the application under test into the same process. ,ince the application components and their tests are in the same process% the tests can invo'e methods in the components% and modify and examine fields in the components.

Test case classes

Android provides several test case classes that extend Test9ase and Assert with Android&specific setup% teardown% and helper methods.
AndroidTestCase

A useful general test case class% especially if you are (ust starting out with Android testing% is AndroidTest9ase. )t extends both Test9ase and Assert. )t provides the +>nit&standard set>p56 and tearDown56 methods% as well as all of +>nit3s Assert methods. )n addition% it provides methods for testing permissions% and a method that guards against memory lea's by clearing out certain class references.
Component/speci ic test cases

A 'ey feature of the Android testing framewor' is its component&specific test case classes. These address specific component testing needs with methods for fixture setup and teardown and component lifecycle control. They also provide methods for setting up moc' ob(ects. These classes are described in the component&specific testing topics$

Activity Testing 9ontent .rovider Testing ,ervice Testing

Android does not provide a separate test case class for <roadcast=eceiver. )nstead% test a <roadcast=eceiver by testing the component that sends it )ntent ob(ects% to verify that the <roadcast=eceiver responds correctly.
ApplicationTestCase

7ou use the ApplicationTest9ase test case class to test the setup and teardown of Application ob(ects. These ob(ects maintain the global state of information that applies to all the components in an application pac'age. The test case can be useful in verifying that the NapplicationO element in the manifest file is correctly set up. 1ote% however% that this test case does not allow you to control testing of the components within your application pac'age.
InstrumentationTestCase

)f you want to use instrumentation methods in a test case class% you must use )nstrumentationTest9ase or one of

14

its subclasses. The Activity test cases extend this base class with other functionality that assists in Activity testing.
Assertion classes

<ecause Android test case classes extend +>nit% you can use assertion methods to display the results of tests. An assertion method compares an actual value returned by a test to an expected value% and throws an AssertionException if the comparison test fails. >sing assertions is more convenient than doing logging% and provides better test performance. <esides the +>nit Assert class methods% the testing A.) also provides the :oreAsserts and IiewAsserts classes$

:oreAsserts contains more powerful assertions such as assert9ontains=egex5,tring% ,tring6% which does IiewAsserts
regular expression matching. contains useful assertions about Iiews. 4or example it contains assert#as,creen9oordinates5Iiew% Iiew% int% int6 that tests if a Iiew has a particular H and 7 position on the visible screen. These asserts simplify testing of geometry and alignment in the >).

)oc% o0'ect classes

To facilitate dependency in(ection in testing% Android provides classes that create moc' system ob(ects such as 9ontext ob(ects% 9ontent.rovider ob(ects% 9ontent=esolver ob(ects% and ,ervice ob(ects. ,ome test cases also provide moc' )ntent ob(ects. 7ou use these moc's both to isolate tests from the rest of the system and to facilitate dependency in(ection for testing. These classes are found in the pac'ages android.test and android.test.moc'. :oc' ob(ects isolate tests from a running system by stubbing out or overriding normal operations. 4or example% a :oc'9ontent=esolver replaces the normal resolver framewor' with its own local framewor'% which is isolated from the rest of the system. :oc'9ontent=esolver also stubs out the notify9hange5>ri% 9ontent"bserver% boolean6 method so that observer ob(ects outside the test environment are not accidentally triggered. :oc' ob(ect classes also facilitate dependency in(ection by providing a subclass of the normal ob(ect that is non& functional except for overrides you define. 4or example% the :oc'=esources ob(ect provides a subclass of =esources in which all the methods throw Exceptions when called. To use it% you override only those methods that must provide information. These are the moc' ob(ect classes available in Android$
Simple moc% o0'ect classes

:oc'Application% :oc'9ontext% :oc'9ontent.rovider% :oc'9ursor% :oc'Dialog)nterface% :oc'.ac'age:anager% and :oc'=esources provide a simple and useful moc' strategy. They are stubbed&out versions of the corresponding system ob(ect class% and all of their methods throw an >nsupported"perationException exception if called. To use them% you override the methods you need in order to provide moc' dependencies. (ote3 :oc'9ontent.rovider and :oc'9ursor are new as of A.) level E.
(esolver moc% o0'ects

:oc'9ontent=esolver provides isolated testing of content providers by mas'ing out the normal system resolver framewor'. )nstead of loo'ing in the system to find a content provider given an authority string% :oc'9ontent=esolver uses its own internal table. 7ou must explicitly add providers to this table using add.rovider5,tring% 9ontent.rovider6. Fith this feature% you can associate a moc' content provider with an authority. 7ou can create an instance of a real provider but use test data in it. 7ou can even set the provider for an authority to null. )n effect% a :oc'9ontent=esolver ob(ect isolates your test from providers that contain real data. 7ou can control the

15

function of the provider% and you can prevent your test from affecting real data.
Conte1ts or testing

Android provides two 9ontext classes that are useful for testing$

)solated9ontext provides an isolated 9ontext% 4ile% directory% and database operations that use this
9ontext ta'e place in a test area. Though its functionality is limited% this 9ontext has enough stub code to respond to system calls. This class allows you to test an application3s data operations without affecting real data that may be present on the device.

=enamingDelegating9ontext provides a 9ontext in which most functions are handled by an existing

9ontext% but file and database operations are handled by an )solated9ontext. The isolated part uses a test directory and creates special file and directory names. 7ou can control the naming yourself% or let the constructor determine it automatically. This ob(ect provides a 2uic' way to set up an isolated area for data operations% while 'eeping normal functionality for all other 9ontext operations.

(unning Tests
Test cases are run by a test runner class that loads the test case class% set ups% runs% and tears down each test. An Android test runner must also be instrumented% so that the system utility for starting applications can control how the test pac'age loads test cases and the application under test. 7ou tell the Android platform which instrumented test runner to use by setting a value in the test pac'age3s manifest file. )nstrumentationTest=unner is the primary Android test runner class. )t extends the +>nit test runner framewor' and is also instrumented. )t can run any of the test case classes provided by Android and supports all possible types of testing. 7ou specify )nstrumentationTest=unner or a subclass in your test pac'age3s manifest file% in the NinstrumentationO element. Also% )nstrumentationTest=unner code resides in the shared library android.test.runner% which is not normally lin'ed to Android code. To include it% you must specify it in a Nuses& libraryO element. 7ou do not have to set up these elements yourself. <oth Eclipse with ADT and the android command&line tool construct them automatically and add them to your test pac'age3s manifest file. (ote3 )f you use a test runner other than )nstrumentationTest=unner% you must change the NinstrumentationO element to point to the class you want to use. To run )nstrumentationTest=unner% you use internal system classes called by Android tools. Fhen you run a test in Eclipse with ADT% the classes are called automatically. Fhen you run a test from the command line% you run these classes with Android Debug <ridge 5adb6. The system classes load and start the test pac'age% 'ill any processes that are running an instance of the application under test% and then load a new instance of the application under test. They then pass control to )nstrumentationTest=unner% which runs each test case class in the test pac'age. 7ou can also control which test cases and methods are run using settings in Eclipse with ADT% or using flags with the command&line tools. 1either the system classes nor )nstrumentationTest=unner run the application under test. )nstead% the test case does this directly. )t either calls methods in the application under test% or it c alls its own methods that trigger lifecycle events in the application under test. The application is under the complete control of the test case% which allows it to set up the test environment 5the test fixture6 before running a test. This is demonstrated in the previous code snippet that tests an Activity that displays a ,pinner widget. To learn more about running tests% please read the topics Testing from Eclipse with ADT or Testing from "ther )DEs.

16

Seeing Test (esults

The Android testing framewor' returns test results bac' to the tool that started the test. )f you run a test in Eclipse with ADT% the results are displayed in a new +>nit view pane. )f you run a test from the command line% the results are displayed in ,TD">T. )n both cases% you see a test summary that displays the name of each test case and method that was run. 7ou also see all the assertion failures that occurred. These include pointers to the line in the test code where the failure occurred. Assertion failures also list the expected value and actual value. The test results have a format that is specific to the )DE that you are using. The test results format for Eclipse with ADT is described in Testing from Eclipse with ADT. The test results format for tests run from the command line is described in Testing from "ther )DEs.
)on%e& and mon%e&runner

The ,DK provides two tools for functional&level application testing$

The >)?Application Exerciser :on'ey% usually called ;mon'ey;% is a command&line tool that sends
pseudo&random streams of 'eystro'es% touches% and gestures to a device. 7ou run it with the Android Debug <ridge 5adb6 tool. 7ou use it to stress&test your application and report bac' errors that are encountered. 7ou can repeat a stream of events by running the tool each time with the same random number seed. The mon'eyrunner tool is an A.) and execution environment for test programs written in .ython. The A.) includes functions for connecting to a device% installing and uninstalling pac'ages% ta'ing screenshots% comparing two images% and running a test pac'age against an application. >sing the A.)% you can write a wide range of large% powerful% and complex tests. 7ou run programs that use the A.) with the mon'eyrunner command&line tool.
2or%ing $it" #ac%age names

)n the test environment% you wor' with both Android application pac'age names and +ava pac'age identifiers. <oth use the same naming format% but they represent substantially different entities. 7ou need to 'now the difference to set up your tests correctly. An Android pac'age name is a uni2ue system name for a .ap' file% set by the ;android$pac'age; attribute of the NmanifestO element in the pac'age3s manifest. The Android pac'age name of your test pac'age must be different from the Android pac'age name of the application under test. <y default% Android tools create the test pac'age name by appending ;.test; to the pac'age name of the application under test. The test pac'age also uses an Android pac'age name to target the application pac'age it tests. This is set in the ;android$target.ac'age; attribute of the NinstrumentationO element in the test pac'age3s manifest. A +ava pac'age identifier applies to a source file. This pac'age name reflects the directory path of the source file. )t also affects the visibility of classes and members to each other. Android tools that create test pro(ects set up an Android test pac'age name for you. 4rom your input% the tools set up the test pac'age name and the target pac'age name for the application under test. 4or these tools to wor'% the application pro(ect must already exist. <y default% these tools set the +ava pac'age identifier for the test class to be the same as the Android pac'age identifier. 7ou may want to change this if you want to expose members in the application under test by giving them pac'age visibility. )f you do this% change only the +ava pac'age identifier% not the Android pac'age names%

17

and change only the test case source files. Do not change the +ava pac'age name of the generated =.(ava class in your test pac'age% because it will then conflict with the =.(ava class in the application under test. Do not change the Android pac'age name of your test pac'age to be the same as the application it tests% because then their names will no longer be uni2ue in the system.
2"at to Test

The topic Fhat To Test describes the 'ey functionality you should test in an Android application% and the 'ey situations that might affect that functionality. :ost unit testing is specific to the Android component you are testing. The topics Activity Testing% 9ontent .rovider Testing% and ,ervice Testing each have a section entitled ;Fhat To Test; that lists possible testing areas. Fhen possible% you should run these tests on an actual device. )f this is not possible% you can use the Android Emulator with Android Iirtual Devices configured for the hardware% screens% and versions you want to test.

Testing from Eclipse with ADT This topic explains how create and run tests of Android applications in Eclipse with ADT. <efore you read this topic% you should read about how to create an Android application with the basic processes for creating and running applications with ADT% as described in :anaging .ro(ects from Eclipse and <uilding and =unning from Eclipse. 7ou may also want to read Testing 4undamentals% which provides an overview of the Android testing framewor'. ADT provides several features that help you set up and manage your testing environment effectively$

)t lets you 2uic'ly create a test pro(ect and lin' it to the application under test. Fhen it creates the test pro(ect% it automatically inserts the necessary <instrumentation> element in the test pac'age3s manifest file. )t lets you 2uic'ly import the classes of the application under test% so that your tests can inspect them. )t lets you create run configurations for your test pac'age and include in them flags that are passed to the Android testing framewor'. )t lets you run your test pac'age without leaving Eclipse. ADT builds both the application under test and the test pac'age automatically% installs them if necessary to your device or emulator% runs the test pac'age% and displays the results in a separate window in Eclipse.

Creating a Test #ro'ect

To set up a test environment for your Android application% you must first create a separate pro(ect that holds the test code. The new pro(ect follows the directory structure used for any Android application. )t includes the same types of content and files% such as source code% resources% a manifest file% and so forth. The test pac'age you create is connected to the application under test by an NinstrumentationO element in its manifest file. The New Android Test Project dialog ma'es it easy for you to generate a new test pro(ect that has the proper structure% including the <instrumentation> element in the manifest file. 7ou can use the 1ew Android Test .ro(ect dialog to generate the test pro(ect at any time. The dialog appears (ust after you create a new Android main application pro(ect% but you can also run it to create a test pro(ect for a pro(ect that you created previously. To create a test pro(ect in Eclipse with ADT$

18

1. )n Eclipse% select ,ile 1 (ew 1 *ther. This opens the Select a Wizard dialog. 2. )n the dialog% in the Wizards drop&down list% find the entry for Android% then clic' the toggle to the left.
,elect Android #est 2ro!ect% then at the bottom of the dialog clic' (ext. The New Android Test Project wiLard appears. 3. 1ext to Test Project Name% enter a name for the pro(ect. 7ou may use any name% but you may want to associate the name with the pro(ect name for the application under test. "ne way to do this is to ta'e the application3s pro(ect name% append the string ;Test; to it% and then use this as the test pac'age pro(ect name. The name becomes part of the suggested pro(ect path% but you can change this in the next step.

4. )n the ontent panel% examine the suggested path to the pro(ect. )f !se de"ault location is set% then the
wiLard will suggest a path that is a concatenation of the wor'space path and the pro(ect name you entered. 4or example% if your wor'space path is /usr/local/workspace and your pro(ect name is MyTestApp, then the wiLard will suggest /usr/local/workspace/MyTestApp. To enter your own choice for a path% unselect !se de"ault location% then enter or browse to the path where you want your pro(ect. To learn more about choosing the location of test pro(ects% please read Testing 4undamentals. C. )n the Test Target panel% set An Existing Android .ro(ect% clic' <rowse% then select your Android application from the list. 7ou now see that the wiLard has completed the Test Target .ac'age% Application 1ame% and .ac'age 1ame fields for you 5the latter two are in the .roperties panel6. D. )n the <uild Target panel% select the Android ,DK platform that the application under test uses. !. 9lic' 4inish to complete the wiLard. )f 4inish is disabled% loo' for error messages at the top of the wiLard dialog% and then fix any problems.
Creating a Test #ac%age

"nce you have created a test pro(ect% you populate it with a test pac'age. This pac'age does not re2uire an Activity% although you can define one if you wish. Although your test pac'age can combine Activity classes% test case classes% or ordinary classes% your main test case should extend one of the Android test case classes or +>nit classes% because these provide the best testing features. Test pac'ages do not need to have an Android *>). Fhen you run the pac'age in Eclipse with ADT% its results appear in the +>nit view. =unning tests and seeing the results is described in more detail in the section =unning Tests. To create a test pac'age% start with one of Android3s test case classes defined in android.test. These extend the JUnit TestCase class. The Android test classes for Activity ob(ects also provide instrumentation for testing an Activity. To learn more about test case classes% please read the topic Testing 4undamentals. <efore you create your test pac'age% you choose the +ava pac'age identifier you want to use for your test case classes and the Android pac'age name you want to use. To learn more about this% please read Testing 4undamentals. To add a test case class to your pro(ect$

1. )n the Project #$plorer tab% open your test pro(ect% then open the src folder. 2. 4ind the +ava pac'age identifier set by the pro(ection creation wiLard. )f you haven3t added classes yet%
this node won3t have any children% and its icon will not be filled in. )f you want to change the identifier value% right&clic' the identifier and select 4efactor O 4ename% then enter the new name. 3. Fhen you are ready% right&clic' the +ava pac'age identifier again and select (ew O 5lass. This displays the New %ava lass dialog% with the Source "older and Package values already set. 4. )n the Name field% enter a name for the test case class. "ne way to choose a class name is to append the string ;Test; to the class of the component you are testing. 4or example% if you are testing the class :yAppActivity% your test case class name would be :yAppActivityTest. Leave the modifiers set to

19

public.

5. )n the Superclass field% enter the name of the Android test case class you are extending. 7ou can also
browse the available classes.

6. )n W&ic& met&od stubs would you like to create'% unset all the options% then clic' ,inish. 7ou will set up
the constructor manually. !. 7our new class appears in a new +ava editor pane. 7ou now have to ensure that the constructor is set up correctly. 9reate a constructor for your class that has no argumentsK this is re2uired by +>nit. As the first statement in this constructor% add a call to the base class3 constructor. Each base test case class has its own constructor signature. =efer to the class documentation in the documentation for android.test for more information. To control your test environment% you will want to override the set p!" and tearDown!" methods$

set p!": This method is invo'ed before any of the test methods in the class. >se it to set up the
environment for the test 5the test fixture. 7ou can use set p!" to instantiate a new )ntent with the action ACT#$%&MA#%. 7ou can then use this intent to start the Activity under test. tearDown!": This method is invo'ed after all the test methods in the class. >se it to do garbage collection and to reset the test fixture. Another useful convention is to add the method test'reconditions!" to your test class. >se this method to test that the application under test is initialiLed correctly. )f this test fails% you 'now that that the initial conditions were in error. Fhen this happens% further test results are suspect% regardless of whether or not the tests succeeded. The =esources tab contains an Activity Testing tutorial with more information about creating test classes and methods.

20

3. Android Activit& Testing

___________________________________
1ow that we have seen the basic elements of an Android Application .ro(ect% letMs loo' deeper into the matter and% for the given pro(ect =oTemps% letMs see what the application can do and then to set out testing goals. 4irst of all we can navigate between pages using a menu. Fhen opening the menu% we can select Send ( and we will be ta'en to a second page% corresponding to a second activity% where we have several fields to fill and after all the process is complete we can submit the form by pressing Send button. #aving all these function in mind we can start planning our testing procedures. 4irst of all we could try to select an option from the available menu and navigate to the Send ( page. LetMs start by creating a new Test .ro(ect and afterwards find a way to simulate touching a button. 4or creating a new test pro(ect we must go to 4ile&O1ew&O"ther&OAndroid Test .ro(ect.

After choosing a name for our Test .ro(ect 5in this case :y4irstTest.ro(ect6% one of the most important steps is choosing for which Android .ro(ect we will write the tests. )n our case we only have one available pro(ect. P 1ote that you can declare a Test .ro(ect for (ust one Android .ro(ect.

21

As we can see in the following capture% the structure of a Test .ro(ect is similar to the structure of the .ro(ect to be tested. 1ow letMs start the actual development of our +>nit test. )n com.rinf.mobile.rotemps.test pac'age we will need to have a +>nit Test 9ase 9lass% so we will create it. 1ow% about the actual code we will start step by step to see how to create a +>nit Test% how to simulate a button press and how to simulate a se2uence of 'eystro'es.
package com.rinf.mobile.rotemps.test; import junit.framework.TestCase; public class ActivityTesting extends TestCase { }

This is the basic test that +ava offers when creating the first +unit Test. <ut we have to change a few lines in order to use this class for Android Testing. The changes are highlighted below$

package com.rinf.mobile.rotemps.test; import com.rinf.mobile.rotemps. endC!; import android.test.Activity"nstrumentationTestCase#; public class ActivityTesting extends Activity"nstrumentationTestCase#$ endC!% olo solo; {

public ActivityTesting&' { (( constructor super& endC!.class'; } protected void set)p&' t*rows +xception { solo , new olo&get"nstrumentation&'- getActivity&''; } protected void tear.own&' t*rows +xception {

22

solo.finis*/penedActivities&'; } }

Fe will use a framewor' 5=obotium6 alongside with +>nit basic testing in order to simplify the access to graphical elements. After creating the test .ro(ect we need to import robotium&solo&B.A.@.(ar into our pro(ect. 4irst it must be downloaded from the address https$??code.google.com?p?robotium?downloads?list. 4or this pro(ect we used version B.A. @. The steps to follow when importing the (ar file are the following$ 1. Test.ro(ect1ame &O right clic'&O .roperties &O +ava <uilder .ath &O Add External +ar. 2. ,earch for the (ar file and select it. 3. *o to Q"rder and Export tab0. 4. 9hec' the box corresponding to robotium&solo&B.A.@.(ar.

4or any new test class there are some conventions that must be ta'en into consideration$ @. 1ame of the test class must end with /Test0 2. 1ame of the method must begin with /test0 A. =eturn type of a test method must be void B. Test method must not throw any exception C. Test method must have any parameter )n case we need to initialiLe some components we must 'now which element corresponds to which id% we must

23

loo' into the layout of the class that will be tested and search for the specific elements that we need to access.

The initialiLation of a certain element must be done in set>p56 method.

protected void set)p&' t*rows +xception { solo , new olo&get"nstrumentation&'- getActivity&''; name+T , &+ditText' solo.get!iew&com.rinf.mobile.rotemps.0.id.et1ame'; }

To run a test we must go to :y4irstTest.ro(ect% right clic' and then go to =un. The second option available is /Android +>nit Test0. This is the proper way to launch a +>nit test.

#ere% we have an example of a test method. The re2uirements are to complete all fields% chec' the 9hec'<ox and after pressing the button we must have displayed the same name as the one entered. The test has the following structure$

2 mallTest public void test3ieldCompletion&' { solo.enterText&name+T- 4my name4'; solo.enterText&5- 4 my address4'; solo.enterText&#- 4t*is is my email4';

24

solo.enterText&6- 475894'; solo.click/nC*eck:ox&7'; solo.click/n:utton&4 end4'; solo.click/n:utton&4;es4'; assertTrue&solo.searc*Text&4my name4'';

After running the test we have the following output$

This means everything went o'% there are no errors and also our Asserts were true. 4or another assertion% such as the one below% the test will fail and we will get a red bar instead of a green one.
assertTrue&solo.searc*Text&4not*ing4'';

4or each test that fails% we also have information about the reasons that led to the failure. 4or the last asset% we are actually searching the ,tring /nothing0 within the current view. 4or the case that one of the TextIiews has the label /nothing0% the test method will not be able to distinguish between the ,tring from the EditText field or the label. )n case we need a more specific search the procedure must be the following$ Declare the EditText element
+ditText name+T;

)n set>p56 method% initialiLe the EditText with its corresponding id

name+T , &+ditText' solo.get!iew&com.rinf.mobile.rotemps.0.id.et1ame';

=etrieve information from EditText

tring name , name+T.getText&'.to tring&';

:a'e the proper Assertion

assert+<uals&4=ary4- name';

4or accessing different elements of the view% we have the following commands$

25

<utton
solo.click/n:utton&4 end4';

EditText
solo.enterText&name+T- 4=ary4'; (( using t*e id of t*e element solo.enterText&5- 4 my address4'; (( using t*e position

PP The counting starts from current view. 9hec'<ox

so the string /my address0 will be inserted in the second EditText field found in the

solo.click/nC*eck:ox&7';

=adio<utton
solo.click/n0adio:utton&7';

Date.ic'er
solo.set.ate>icker&7- year- mont*- day';

)mage<utton
solo.click/n"mage:utton&7';

4or a button that has no text displayed 5is (ust an image6 we have the following method of access$ Declare the element as a button
:utton buttonview ;

*et the corresponding id for the element 5in set>p56 method6

buttonview , &:utton' solo.get!iew&com.example.findit?5@7@5.0.id.b@add@ot*er@save';

Access the element 5inside the test method6

solo.click/n!iew&buttonview';

Also we can search for a specific ,tring in the current view using solo.searc*Text&4/A;6. <ut as this se2uence offers as output a <oolean% it is more suitable to be used for an Assertion 5as in 2 mallTest example6. 4or a ,pinner% the proper way of accessing it is$
solo.press pinner"tem&int solo.go:ack&'; pinner"ndex- int "tem"ndex';

Another useful command is the one that simulates <ac' button.

26

4. Android Service Testing

___________________________________
2"at is a Service5 A ,ervice is an application component without a user interface that runs in the bac'ground and can perform long& running operations. )t can be started by another application component and will continue to run in the bac'ground even if the user switches to another application. A service can ta'e two forms$ ,tarted A service is ;started; when an application component 5such as an activity6 starts it by calling startSer(ice!". "nce started% a service can run in the bac'ground indefinitely% even if the component that started it is destroyed. >sually% a started service performs a single operation and does not return a result to the caller. <ound A service is ;bound; when an application component binds to it by calling bind,ervice56. A bound service offers a client&server interface that allows components to interact with the service% send re2uests% get results% and even do so across processes with interprocess communication 5).96. A bound service runs only as long as another application component is bound to it. :ultiple components can bind to the service at once% but when all of them unbind% the service is destroyed. ,ervice Lifecycle-from when it3s created to when it3s destroyed-can follow two different paths$ A started service The service is created when another component calls start,ervice56. The service then runs indefinitely and must stop itself by calling stop,elf56. Another component can also stop the service by calling stop,ervice56. Fhen the service is stopped% the system destroys it A bound service The service is created when another component 5a client6 calls bind,ervice56. The client then communicates with the service through an #)inder interface. The client can close the connection by calling unbind,ervice56. :ultiple clients can bind to the same service and when all of them unbind% the system destroys the service. 5The service does not need to stop itself.6

27

6. Content #rovider Testing

___________________________________
9ontent providers manage access to a structured set of data. They encapsulate the data and also provide mechanisms for defining data security. 9ontent providers are the standard interface that connects data in one process with code running in another process. A content provider component supplies data from one application to others on re2uest. ,uch re2uests are handled by the methods of the 9ontent=esolver class. A content provider can use different ways to store its data and the data can be stored in a database% in files% or even over a networ'. Each Android applications runs in its own process with its own permissions which 'eeps an application data hidden from another application. <ut sometimes it is re2uired to share data across applications. This is where content providers become very useful. )n our case we need to store the information provided by the user in the ,end 9I 4orm and display it in the message that will be submitted in the following stage. 4irst of all ) decided that the data will be stored with the use of ,hared.references. )n this case% the saving procedure is the following$
my *ared>references , t*is.getActivity&'.get *ared>references&4=;@>0+3 4Context.=/.+@>0"!AT+'; *ared>references.+ditor editor , my *ared>references.edit&';

#ere we used an editor and stored each specific information with a corresponding name
editor.put tring&4name4- getApplicant1ame';

4or retrieving the stored information we need to use the following command.
getApplicant1ame , my *ared>references.get tring&4name4- null';

To test if our data is passed from one activity to another% a simple test is to actually go to the layout where we have displayed this information and visually chec' it. This can be done by creating a test where we insert a specific string and at the end of the test create an assert statement where we actually chec' out input data and the output one.

28

7. 8nline Documentation

___________________________________
http://www.vogella.com/tutorials/AndroidTesting/article.html http://www.fhnw.ch/technik/imvs/publikationen/vortraege-20 0/android-testing http://agile.csc.ncsu.edu/!"#aterials/$hite%o&.pdf http://www.vogella.com/tutorials/'(nit/article.html http://developer.android.com/tools/testing/inde&.html http://)unit.sourceforge.net/doc/cookbook/cookbook.htm https://code.google.com/p/robotium/

29