/pcq/media/agency_attachments/L8pkS8gpnodJThOdAfv1.jpg)
Follow UsJava SE has support for something called 'Reflections'. Reflections is a
set of classes that make unit testing a breeze because it allows runtime code to
programmatically examine an object and get its metadata (like proper ties,
methods, and so on).
Now, mobile applications are programmed using the CLDC (Connect-ed Limited
Device Configuration) framework. CLDC is a set of base application programming
interfaces as well as a virtual machine needed to work with devices like pagers
and mobile phones. CLDC used in conjunction with MIDP (Mobile Information Device
Profile) makes for a very powerful platform to work with mobile devices.
However, this is a stripped down version of Java SE and does not feature any
support for reflections. Thus, developers are left stranded with no way to do
unit testing of their mobile applications. The otherwise universal testing
choice for Java SE applications is JUnit (a unit testing framework) which in
turn uses the Reflections API in Java SE. JMUnit is the alternative here which
is styled similar to JUnit and this can come in handy for testing mobile
applications. Let's see how you can put this to use.
/pcq/media/post_attachments/4adca23b6ac1fd74a524c1840dc6a70e9a8b3da38237e02dec79440360164843.gif) |
|
|
Configuration
You can download the latest version of the framework (1.0.1 at the time of going
to press) from the URL mentioned above. It is a small ZIP file that can be
extracted to any location in your hard drive. Once extracted you need to make
sure that the two jars in the 'dist' folder under the extracted directory
viz. JMUNIT4CLDC10.jar and JMUNIT4 CLDC11.jar are in the CLASSPATH for your
compiler or IDE environment. We'll talk about when and where these two are to
be used, a bit later.
Basics
CLDC has two versions-1.0 and 1.1. The difference (in our case) lies in the
presence of floating point primitive data type in CLDC 1.1, while in CLDC 1.0
you will have to use integer type primitives. It is for this reason that we have
two different JAR files for usage with these two profiles.
Like JUnit this framework also works on assertions. It has all the assertions as
JUnit and few more. The assertions used are assertTrue(), assertFalse(), assert
Same(), assertNotSame(), assert Equals(), assertNotEquals(), and assert Null().
The difference for CLDC 1.0 and CLDC 1.1 lies in the assertEquals() method for
floating type primitive that CLDC 1.1 has.
Using the TestCase class
The TestCase is the same as the one you would have encountered in Java SE unit
testing. You first need to create a sub-class of the TestCase class provided in
the jmunit.framework.cldc1X package (replace X with 0 or 1 as per the CLDC
version). And it is always a good practice to use 'Test' as a suffix in this
sub-class. The TestCase is an abstract class with one constructor and one
abstract method.
public void test(int testNumber) throws Throwable;
/pcq/media/post_attachments/8fd53ac5a120a41bbaf908e16602130e20ba83cd5dffbb5cfdc9b92c8778be60.jpg) |
| JMUnit allows unit testing of mobile applications without using Reflections |
All the sub-classes have to implement this method. A sample TestCase class
would look like this:
public class PCQTest extends TestCase{
public PCQTest(){
super(2,
”PCQ Sample Test”);
}
public void test(int testNumber) throws Throwable{
switch(testNumber){
case 0:
testPCQConvert();
break;
case 1:
testPCQAdd();
break;
default: break;
}
}
}
The constructor has a call to the super class with two arguments. The first
argument is an integer type primitive specifying the number of tests in your
test case and the second is a String, which conventionally should be used for
identification of the test case. Notice that we have passed the integer 2 in the
argument and the case numbers under switch statement starts from zero. The test
method we implemented is the one responsible for testing your code. You can
place calls for methods implementing the tests in this switch statement. A
simple implementation of one such method is as follows:
public void testPCQAdd() throws
AssertFailedException{
PCQTest test = new PCQTest();
assertTrue(test.isEmpty());
test.add(new Object());
assertFalse(test.isEmpty());
assertEquals(test.add(4,5),9);
}
Every method that you implement for testing, that uses assertion methods,
should include the 'throws' clause with AssertFailedException. The exception
is raised by the framework to identify the failure of a test.
Test suites
The Java ME applications are very small in comparison with other Java
appli-cations and a good part of their code is very difficult to test
(multithreading and GUI, for example), so the tests required are usually very
small, but are big enough to need a few test cases. If you need to execute more
than one, you can use a Test Suite.
It's a good option to manage the test cases in specific modules too, if all
of them don't fit in only one. As it's possible to use the JMUnit in
applications with a target device more complex than a mobile phone (like a PDA)
and capable of executing much more complicated code, in future releases, it's
going to be possible to create many test cases, put them in different test
suites and then, put all of them in a test suite root. To create a test suite,
you first need one or more test case. You must create a sub-class of
jmunit.framework. cldc1X.Test Suite. This abstract class has a const-ructor with
one String parameter used to identify the test suite. It is not useful if
there's only one in the entire application. You can put 'Test Suite' or
something else, but if there are many of them, it helps to see what's running.
public class PCQTestSuite
extends TestSuite{
public PCQTestSuite(){
super(“PCQ Tests”);
}
}
In conclusion
It's a framework that can come in handy for unit testing of Java ME
applications. The website mentions that the project will soon be merged with
J2MeUnit. Want to know what that means? Wait till the next part of this series.
We will cover more in testing and coding mobile
applications in the coming issues.
Anadi Misra