270 likes | 558 Views
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
E N D
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 • Creating the Test Case Class
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_android.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 JUnitTestCase • package android.test. 1. JUnit test case classes • extend the JUnitTestCase 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 JUnitAssert • 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.