Sergio Morozov
A really short & concise guide.
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 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 setUp() and/or 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 "com.foo.bar.AbcTest" 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 TestFailure class. 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 printTrace() only prints it to the standard error output. This is the only possible way to get it.
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 setUp() method to set this variables,
and/or overriding tearDown() method to clean up after test execution
implementing test() method to perform test and assert the results.
For example traditional AddTest:
import momeunit.framework.TestCase;
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;
assertEquals("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;
assertEquals("And what again?", 3, res);
}
}
Each test runs in its own fixture. So there are no side effects concerning test runs.
Tests can be executed by using any test runner. This framework provides as an extension a MIDletTestRunner - a fully configurable (colors, fonts, tests hierarchy, auto-run and print features) 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. Tests can be run automatically during start-up (depends on configuration) and re executed more times later. It can print descriptive messages of failures and errors thrown together with stack-trace to the standard error output. 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 run() method.
result = new Addtest().run()
To run a bunch of test cases use a TestSuite class. Instantiate a test suite using 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 run() 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();
suite.run(res);
It is possible of course to add other tests to Test suite after creation of test suite by calling addTest( Class ) or addTest( String ) methods with class or name of class implementing Test interface or calling addTest( Test ) method with Test instance.
Sergio Morozov. 2007