Package momeunit.framework

MoMEUnit is an instance of the xUnit architecture for unit testing of J2ME applications.


Interface Summary
Test A Base interface that all tests should implement.
TestListener A Listener for test progress

Class Summary
Assert A collection of static assert methods.
TestCase An abstract class that every test case should extend.
TestFailure Describes a test failure or error.
TestResult A class that collects the results of execution of tests.
TestSuite A collection of tests that can be processed together.

Error Summary
AssertionFailedError An Error thrown when an assertion fails.

Package momeunit.framework Description

MoMEUnit is an instance of the xUnit architecture for unit testing of J2ME applications. It is derived from JUnit framework. It is only CLDC 1.1 complied.


The main problem of using JUnit frameork in development of J2ME applications is a lack of reflection API in MIDP API. So it is impossible to keep implicit association between the test method name and name of test case. In my humble option, if it is not possible, we shouldn't do this. This framework doesn't make use of test<TestName> method signature. It introduces only one test method:

 public void test() throws Throwable

Different tests can be created by different subclasses of TestCase class. Sharing of the same fixture between different tests is realized via subclassing. One approach is to create one subclass of TestCase by overriding TestCase.test() method and fixture methods and defining instance variables to store the state of the fixture. Other tests will extend this test sharing the same fixture. It is of course possible to override fixture methods (e.g. to add additional functionality) and add other instance variables if needed. Another more general approach is to create abstract TestCase subclass overriding TestCase.setUp() and/or TestCase.tearDown() methods, defining instance variables to store the state of the fixture. All test cases will extend this abstract class (But, to my mind, this is just a waste of time and memory). In both cases we can keep implicit association between name of TestCase subclass and name of test case. In this framework the default test case name is name of TestCase subclass without 'packages' prefix (e.g. for class "" the name of test case will be "AbcTest"). Each test runs in its own fixture of course. So there are no side effects concerning test runs.

The other minor changes to the JUnit framework are the absence of ComparisonFailure class and modification to TestResult, TestFailure classses. The only function of ComparisonFailure class is just processing of strings to show only different parts of them in the assertion message. To my mind such a class is redundant in J2ME test framework. Of course this functionality is useful especially taking into consideration limited characteristics of display of devices. So it is putted in respective assertEquals methods of Assert class. In this framework TestResult class contains only one registered TestListener instead of collection. To my mind one listener is definitely enough in J2ME testing framework. To use a collection of registered TestListeners create TestListener implementation that contains a collection of test listeners and propagates test events to them. It is also impossible to get stack-trace of thrown exception as a String. So TestFailure method TestFailure.printTrace() only prints it to the standard error output. This is the only possible way to get it.

Creating Tests

Creating of tests is pretty simple I shortly described this above. Create a TestCase subclass by defining instance variables to store the state of the fixture, overriding TestCase.setUp() method to set this variables, and/or overriding TestCase.tearDown() method to clean up after test execution, implementing TestCase.test() method to perform test and assert the results. For example traditional AddTest:

 public class AddTest extends TestCase
   protected int arg1;
   protected int arg2;
   protected void setUp()
     this.arg1 = 2;
     this.arg2 = 5;
   public void test()
     int res = arg1 + arg2;
     assertEqual("I don't know what happened", 7, res);

To create another test that shares the same fixture just subclass this class. For example traditional SubtractTest:

 public class SubtractTest extends AddTest
   public void test()
     int res = arg2 - arg1;
     assertEqual("I again don't know what happened", 2, res);

Each test runs in its own fixture. So there are no side effects concerning test runs.

Running tests

Tests can be executed by using any test runner. This framework provides as an extension a MIDletTestRunner - a fully configurable MIDlet. It runs tests in emulator (e.g. WTK emulator) and shows the results (progress bar, statistics, lists of failures or errors with detailed messages) in one screen. In my humble option pretty good test runner for J2ME applications.

It is, of course, possible to run test case or hierarchy of test cases without test runner.

To run a specific test case and obtain results just call method. For example:

 result = new Addtest().run()

To run a bunch of test cases use a TestSuite class. Instantiate it by calling a constructor that takes array of classes or array of strings as arguments with array of classes or names of classes implementing Test interface and call momeunit.framework.TestResult ) method.

 TestSuite suite = new TestSuite("ArithmeticTest", new Class[] { AddTest.class,
     SubtractTest.class });
 // TestSuite suite = new TestSuite("ArithmeticTest", new String[] { "AddTest", "SubtractTest" });
 TestResult res = new TestResult();;

It is possible of course to add other tests to test suite after creation of test suite by calling TestSuite.addTest( Class ) or TestSuite.addTest( String ) methods with class or name of class implementing Test interface or calling TestSuite.addTest( momeunit.framework.Test ) method with Test instance.

Sergio Morozov