Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

JUnit Testing Using Java ME JUnit Frameworks : Page 4

Just because Java Micro Edition lacks reflective capabilities doesn't mean Java Micro Edition developers miss out on the advantages of JUnit styled testing. JUnit-styled frameworks and tools can still improve ME application quality.


advertisement
Working with J2MEUnit

Setting up J2MEUnit
The alternative to JMUnit is J2MEUnit. It, too, is downloaded via Sourceforge. Unlike JMUnit, there is only one version of J2MEUnit and thus only one .jar file. The current release is labeled 1.1.1.

J2MEUnit Test Cases
Test cases in J2MEUnit must inherit from j2meunit.framework.TestMethod. Like in JMUnit, your tests are implemented in test methods and conventionally named test+methodNameToBeTested. Unlike JMUnit, test methods are not required to throw any exception.



Importantly, J2MEUnit does not support as full or rich set of assert methods as does JMUnit. J2MEUnit only supports the following assertions:

assertTrue(expression) assertSame(expected,actual) assertEquals(expected,actual) assertNotEquals(expected,actual) assertNull(object)

Even these methods are not as overloaded as in JMUnit. As an example, Table 1 presents the types of expected versus actual types that can be compared in JMUnit's assertEquals method (both CLDC 1.0 and CLDC 1.1 versions) against J2MEUnit's assertEquals method. That's quite a few methods, especially in applications that use the new floating point types in CLDC 1.1.

 

JMUnit assertEquals

for CLDC 1.0

JMUnit assertEquals

for CLDC 1.1

J2MEUnit assertEquals

Expected value /result value

type support

Object

String

boolean

byte

char

int

long

short

Object

String

boolean

byte

char

double

float

int

long

short

Object

long

Except for the lack of assertion methods, J2MEUnit test case methods do not vary greatly from JMUnit test case methods. Example test methods for the DistanceConverstionTest are provided in Listing 1. Note the missing thrown exception; otherwise the methods look the same.

Like JUnit and JMUnit, J2MEUnit provides setup, teardown, and fail methods that can be overridden in test cases.

J2MEUnit TestSuite
The creation and execution of suites in J2MEUnit varies quite a bit from JMUnit. J2MEUnit suites are more reminiscent of regular JUnit suites (except for the lack of reflection).

In order to create a test suite in J2MEUnit, you typically create a suite() method in your test case class. This aligns closely with JUnit, although in J2MEUnit, the suite method can be an instance method. In regular JUnit, the suite method is a static method. The suite method returns an instance of j2meunit.framework.TestSuite. This object contains all the test methods for all the test cases that are desired.

Adding a test method for a test case to the suite can seem a little convoluted. The best way to add a test method to the suite is to create and use an instance of j2meunit.framework.TestMethod. TestMethod is actually an interface that stipulates a single run(TestCase) method be provided by implementing classes. TestMethods are generally implemented with an anonymous inner class. Here is how to add a TestMethod to the suite for the testfeetToMeters method:

public Test suite() { TestSuite suite=new TestSuite(); suite.addTest(new DistanceConverstionTest("testfeetToMeters", new TestMethod(){ public void run(TestCase tc){ ((DistanceConverstionTest) tc).testfeetToMeters(); } } )); return suite; }

Of course, the other methods in DistanceConversionTest need to be added to the suite similarly, and the suite method also necessitates the creation of a test case constructor.

public DistanceConverstionTest(String testName, TestMethod testMethod) { super(testName, testMethod); }


Figure 4. A Successful Test Suite Execution.: Output using J2MEUnit is not as glitzy as JMUnit, but it still gets the pertinent information to the developer. The first screen shows the status of execution and the second screen displays the final results.
 
Figure 5. A Failure Test Case: More detailed information is provided in J2MEUnit on failures such as which test failed and what values were expected.

Executing J2MEUnit Tests
J2MEUnit test cases are not MIDlet sub classes as in JMUnit. Instead, J2MEUnit offers two implementations of a TestRunner class that allow you to execute your tests. j2meunit.textui.TestRunner parallels the idea in the regular JUnit's TestRunner. 2meunit.textui.TestRunner can only be executed from command line environments. Therefore, the preferred way to run J2MEUnit tests is to use the other TestRunner implementation. j2meunit.midletui.TestRunner is a MIDlet that you extend. As a MIDlet, j2meunit.midletui.TestRunner runs in an emulator (or real device).

Overrideing the startApp() method is the only thing you need to code in your TestRunner MIDlet class. In the startApp method call on TestRunner's start method with an array of Strings containing the names of your test case classes:

public class ConversionTestRunnerMIDlet extends TestRunner { protected void startApp() { start(new String[] {"com.white.tests.j2meunit.DistanceConversionTest", "com.white.tests.j2meunit.TemperatureConversionTest"}); } }

Figure 6. Console Output: As with JMUnit, more detailed information is provided in the console window when executing J2MEUnit test cases. This is especially true in the case of failures.

Alternately, J2MEUnit allows for passing test cases to the MIDlet and executing the TestRunner directly by setting a J2MEUnitTestClasses property in the JAD file or JAR's manifest file. The J2MEUnitTestClasses property should contain a list of your test case classes.

The TestRunner MIDlet does not provide as flashy graphical results as JMUnit (see Figure 4), but on failures (see Figure 5), it does provide information in the emulator (unlike JMUnit).

As with JMUnit, more detailed information about the tests, especially failures, can be found in the resulting console window (see Figure 6).



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap