As we all know, to test android application UI (I mean the Activity), the only way exposed by Android is Activity Instrumentation framework. Since Activity itself has complex life cycle, the activity cannot be invoked other than Instrumentation.
Here are the list of stuffs Activity Instrumentation framework does for us.
• Lifecycle control:
With instrumentation, you can start the activity under test, pause it, and destroy it, using methods provided by the test case classes.
• Dependency injection:
Instrumentation allows you to create mock system objects such as Contexts or Applications and use them to run the activity under test. This helps you control the test environment and isolate it from production systems. You can also set up customized Intents and start an activity with them.
• User interface interaction:
You use instrumentation to send keystrokes or touch events directly to the UI of the activity under test.
Let’s discuss on the key features of Android testing framework
• Android test suites are based on JUnit. You can use plain JUnit to test a class that doesn’t call the Android API, or Android’s JUnit extensions to test Android components. If you’re new to Android testing, you can start with general-purpose test case classes such as AndroidTestCase and then go on to use more sophisticated classes.
• The Android JUnit extensions provide component-specific test case classes. These classes provide helper methods for creating mock objects and methods that help you control the lifecycle of a component.
• Test suites are contained in test packages that are similar to main application packages, so you don’t need to learn a new set of tools or techniques for designing and building tests.
• The SDK tools for building and tests are available in Eclipse with ADT, and also in command-line form for use with other IDEs. These tools get information from the project of the application under test and use this information to automatically create the build files, manifest file, and directory structure for the test package.
• The SDK also provides monkeyrunner, an API for testing devices with Python programs, and UI/Application Exerciser Monkey, a command-line tool for stress-testing UIs by sending pseudo-random events to a device.
Android testing API
As mentioned earlier, the Android testing API is built with JUnit framework and has extended the Instrumentation framework and Android specific classes.
Here are the details of the API
You can use the JUnit TestCase class to do unit testing on a class that doesn’t call Android APIs. TestCase is also the base class for AndroidTestCase, which you can use to test Android-dependent objects. Besides providing the JUnit framework, AndroidTestCase offers Android-specific setup, teardown, and helper methods.
You use the JUnit 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 UI. These are described in more detail in the section Assertion classes
To learn more about JUnit, you can read the documentation on the junit.org home page. Note that the Android testing API supports JUnit 3 code style, but not JUnit 4. Also, you must use Android’s instrumented test runnerInstrumentationTestRunner to run your test case classes. This test runner is described in the section Running Tests.
Android instrumentation is a set of control methods or “hooks” in the Android system. These hooks control an Android component independently of its normal lifecycle. They also control how Android loads applications.
Normally, an Android component runs in a lifecycle determined by the system. For example, an Activity object’s lifecycle starts when the Activity is activated by an Intent. The object’s onCreate() method is called, followed by onResume(). When the user starts another application, the onPause() method is called. If the Activity code calls the finish()method, the onDestroy() method is called. The Android framework API does not provide a way for your code to invoke these callback methods directly, but you can do so using instrumentation.
Also, the system runs all the components of an application into the same process. You can allow some components, such as content providers, to run in a separate process, but you can’t force an application to run in the same process as another application that is already running.
With Android instrumentation, though, you can invoke callback 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.
You can find more details on Android fundamentals from the following pages and the same is source for the above contents I mentioned.