Instrumentation and JUnit
Muthu Ramadoss
JUnit has been nicely integrated into Android. JUnit classes are
specialized to facilitate common Android testing tasks. In this post, I
will talk about my experiences with InstrumentationTestRunner and the
facilities it provides to integrate Android instrumentation with JUnit
test execution.
As we have seen previously, the difficulty in JUnit-instrumentation
integration stems from the fact that an instrumentation is an entire
Android application, started, managed and terminated for testing
purposes. One has to work quite a bit to make sure that the test
controller is not terminated along with the application under test.
InstrumentationTestRunner solves this problem by launching the Dalvik VM
in special, instrumentation mode.
You can download the example program from here.
The test subject is our well known Calculator program that was renamed
as Calculator2 so that we do not confuse it with the version coming from
previous application packages, other than that it is the same simple
program. Under aexp.calculator.tests, you will find two JUnit test
classes. There are things to note, however.
* Instead of TestCase, the test classes inherit from
ActivityInstrumentationTestCase, templated by the activity class under
test.
* The constructor of the test class defines the activity under test
class precisely.
One such test class or collection of test classes can be executed by
InstrumentationTestRunner. Execute the following command (from command
prompt).
adb shell am instrument -w
aexp.calculator/android.test.InstrumentationTestRunner
The console of the command prompt reads like this:
aexp.calculator.tests.AddFunctionalTests:...
aexp.calculator.tests.SubFunctionalTests:...
Test results for InstrumentationTestRunner=......
Time: 11.448
OK (6 tests)
Meanwhile, the emulator main window flashes with action. Calculator2 is
launched 4 times, each time the key input is automatically provided by
the test case. All this is arranged by the Android specialization of
TestCase/TestRunner.
Please observe the AndroidManifest.xml of the project. Check out the
uses-library tag and the use of instrumentation tag, particularly the
targetPackage attribute that refers to the application package under
test (and not the Java package name of the test classes).
InstrumentationTestRunner automagically looks for test classes that fit
the test execution criteria (again, check out InstrumentationTestCase
documentation for options), there was no need to organize the test
classes into suites.
Note that the arrangement of this project is not typical. I mixed the
test classes and the activity under test into the same application. This
eliminates a lot of deployment problems that caused so much trouble for
so many people when playing with the Android test framework. The typical
deployment, however, is to place the test classes and application under
test into separate application packages. I will get to that in the next
post.
http://mylifewithandroid.blogspot.com/2008/12/instrumentation-and-junit.html
--
Thanks.
Muthu Ramadoss
http://mobeegal.in - mobile search. redefined. (+91 9840348914)
http://linkedin.com/in/tellibitz