Content Testing In Eclipse, with ADT Android Testing Framework 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

Creating the Test Case Class

android.test.ActivityInstrumentationTestCase2

Testing In Eclipse, with ADT Import com.zy.helloandroid.HelloAndroid; public HelloAndroidTest() { super("com.zy.helloandroid", HelloAndroid.class); }

Android Testing Framework. roid.html 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 element in the test application's manifest file

The Testing API extend the JUnit TestCaseTestCase package android.test.android.test 1. JUnit test case classes extend the JUnit TestCase but do not use the instrumentation framework.TestCase contain methods for accessing system objects like Context The base class is AndroidTestCase, but you usually use a subclass associated with a particular component.AndroidTestCase ApplicationTestCase - A class for testing an entire application ApplicationTestCase ProviderTestCase2 - A class for isolated testing of a single ContentProvider. ProviderTestCase2 ContentProvider ServiceTestCase - a class for isolated testing of a single Service. ServiceTestCase 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.InstrumentationTestCase The subclasses are: ActivityTestCase - A base class for activity test classes. ActivityTestCase SingleLaunchActivityTestCase - A convenience class for testing a single activity SingleLaunchActivityTestCase SyncBaseInstrumentation - A class that tests synchronization of a content provider. SyncBaseInstrumentation ActivityUnitTestCase - This class does an isolated test of a single activity. ActivityUnitTestCase ActivityInstrumentationTestCase2 - This class tests a single activity within the normal system environment. ActivityInstrumentationTestCase2

The Testing API 3. Assert classes extends the JUnit AssertAssert two extensions : MoreAsserts :contains more powerful assertions MoreAsserts such as assertContainsRegex(String, String)assertContainsRegex(String, String) ViewAsserts :contains useful assertions about Android Views. ViewAsserts such as assertHasScreenCoordinates(View, View, int, int)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:android.testandroid.test.mock IsolatedContext - Mocks a Context so that the application using it runs in isolation. This class is useful in unit testing. IsolatedContext 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. RenamingDelegatingContext 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. MockApplicationMockContentResolverMockContext MockDialogInterfaceMockPackageManager MockResources

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() : 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!!!