Android Testing

Download Report

Transcript Android Testing

Content

Testing In Eclipse, with ADT

http://androidappdocs.appspot.com/resources/tutorials/testing/helloandroid_test.html

Android Testing Framework

http://androidappdocs.appspot.com/guide/topics/testing/testing_android.html
 1. Overview
 2. The Testing API
 3. Working in the Test Environment
Testing In Eclipse, with ADT



Target: an HelloAndroid application
It runs like this:
Testing abjective:
To test if textview shows the right string as defined in string
resource
Testing In Eclipse, with ADT

Creating the Test Project
1. In Eclipse, select New > Project > Android > Android Test
Project>next
Testing In Eclipse, with ADT
Testing In Eclipse, with ADT
Testing In Eclipse, with ADT

Creating the Test Case Class

android.test.ActivityInstrumentationTestCase2<HelloAndroid>
Testing In Eclipse, with ADT


Import com.zy.helloandroid.HelloAndroid;
public HelloAndroidTest() {
super("com.zy.helloandroid",
HelloAndroid.class);
}
Android Testing Framework.

http://androidappdocs.appspot.com/guide/topics/testing/testing_and
roid.html
1. Overview
 2. The Testing API
 3. Working in the Test Environment

overview:
extensions to the JUnit framework
 An instrumentation framework
 Mock versions of commonly-used Android system
objects.
 Tools for running single tests or test suites, with or
without instrumentation.
 Support for managing tests and test projects in the ADT
Plugin for Eclipse and at the command line.

overview:
Your test application is linked to the application under test by means of
an <instrumentation> element in the test application's manifest file
The Testing API


extend the JUnit TestCase
package android.test.
1. JUnit test case classes
 extend the JUnit TestCase but do not use the
instrumentation framework.
 contain methods for accessing system objects like Context
 The base class is AndroidTestCase, but you usually use a
subclass associated with a particular component.
 ApplicationTestCase - A class for testing an entire
application
 ProviderTestCase2 - A class for isolated testing of a single
ContentProvider.
 ServiceTestCase - a class for isolated testing of a single
Service.
The Testing API
2. Instrumentation test case classes
 uses the instrumentation framework. With instrumentation:
 automate UI
 precisely control the start of an activity
 monitor the state of the activity during its life cycle.
 The base class is InstrumentationTestCase.
 The subclasses are:
 ActivityTestCase - A base class for activity test classes.
 SingleLaunchActivityTestCase - A convenience class for testing
a single activity
 SyncBaseInstrumentation - A class that tests synchronization of
a content provider.
 ActivityUnitTestCase - This class does an isolated test of a single
activity.
 ActivityInstrumentationTestCase2 - This class tests a single
activity within the normal system environment.
The Testing API
3. Assert classes
 extends the JUnit Assert
 two extensions :
 MoreAsserts :contains more powerful assertions
such as assertContainsRegex(String, String)

ViewAsserts :contains useful assertions about
Android Views.
such as assertHasScreenCoordinates(View, View, int,
int)
The Testing API
4. Mock object classes
 creating mock system objects such as applications,
contexts…
 found in android.test and android.test.mock. They are:
 IsolatedContext - Mocks a Context so that the application
using it runs in isolation. This class is useful in unit testing.
 RenamingDelegatingContext - Delegates most context
functions to an existing, normal context while changing the
default file and database names in the context. Use this to
test file and database operations with a normal system
context, using test names.
 MockApplication, MockContentResolver, MockContext,
MockDialogInterface, MockPackageManager,
MockResources - Classes that create mock Android
system objects for use in testing. They expose only those
methods that are useful in managing the object.
The Testing API
5. InstrumentationTestRunner
 a custom class for running tests.
 controls of the application under test, runs
the test application and the main application
in the same process.
 control the entire test environment at
runtime.

Working in the Test Environment
1. Working with test projects
Use Android tools to create a test project for
your project under test.
 The tools create the project directory and the
files and subdirectories needed.
 The tools also create a manifest file that
links the application in the test project to the
application under test

Working in the Test Environment
2. Working with test case classes
 A test application contains one or more test
case classes that extend an Android test case
class.
 choose a test case class based on the type of
Android component you are testing and the
tests you are doing.
 A test application can test different components,
 but each test case class is designed to test a
single type of component.
 Some Android components have more than one
associated test case class.
Working in the Test Environment
3. Working with test methods
 Each test case class provides methods that you use to set up the test
environment and control the application under test.
 you add methods to the class to define individual tests.
 Each method you add is run once each time you run the test
application.
special methods:
 setUp() :





invoked before any of the test methods in the class.
Use it to set up the environment for the test.
call super.setUp() as the first statement in your code.
runs before each of your methods.
tearDown():
 invoked after all the test methods in the class.
 Use it to do garbage collection and re-setting before moving on to the next set of
tests.
 you must call super.tearDown() as the last statement in your code.
 run once after each of your methods.
Working in the Test Environment
4. Running tests and seeing the results
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
 the output appears in a new JUnit view
pane.
Working in the Test Environment
5. What to Test
 Activity lifecycle events: You should test that
your activities handle lifecycle events correctly.
 Database operations: You should ensure that
database operations correctly handle changes
to the application's state.
 Screen sizes and resolutions: make sure to
test it on all of the screen sizes and densities on
which you want it to run
 When possible, you should run these tests on
an actual device.
Thank you!!!