|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
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. |
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 "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
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 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.
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
TestCase.run()
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
TestSuite.run( 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(); suite.run(res);
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.
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |