Skip to main content

ME application testing - MIDlet instantiation

Posted by alexeyp on July 8, 2007 at 3:09 AM PDT

The very common problem people meet when trying to unit-test
MIDlets is that you generally can not do something like this:

class MyTest
TestCase {

test() {

MyMIDletApplication myma = style="font-weight: bold; color: rgb(51, 51, 255);">new
 style="font-weight: bold; color: rgb(51, 51, 255);">MyMIDletApplication();

    assertEquals("Never get here", 7, 8);



MIDP spec prohibits calling MIDlet constructor from
code, for
security reasons MIDlet can be instantiated only by AMS, Application
Software. All MIDP xUnit-like test frameworks, I am aware of, assume
that test execution is done by a special utility MIDlet, lets call it
MIDletTester, for example. Since it is not possible to get instance
of your application MIDlet class from the MIDletTester, unit
testing should be limited to library classes.

Here are couple of ideas, we consider implementing some of
them for

Provisioning server and instrumentation

Ideally, testing should be done on the instance, that runs in
environment, that is closest to real. Though you have to test every
unit of the program in isolation, it would also
be useful to have possibility to execute some tests on the MIDP
application, that is packaged and instantiated in a regular way, not on
library classes, packaged with your test application.

This can be done by adding hooks to the application, where you
embed your tests. This approach will require the control over the
application code, may
not always be possible.

If you supply minimalistic xUnit-like test framework with a
responsible for  packaging and provisioning of the test
application, you can implement a solution for this and for some other
MIDP-specific testing problem by using instrumentation of the compiled
application class files to embed whatever hooks you need. Check the


You need to modify the MIDlet class of your application under test with:

  • one or many methods, that will run tests. For
    example instantiate a test
    class by a classname and call its methods.
  • for each test to pass its classname, for example hardcode
    the newly generated method or in a resource file
  • add a mechanizm to call these methods. 

Interesting question is where calling of a test method makes sense. I
think having a UI for it, a Command is not a good idea - after all we
do all this so that testers click mouse less. Placing it into
any specific place in startRun may not work well ... may be I want
this MIDlet instance after startRun was called by AMS.

Potential approach here would be to rename all
methods that can be called by AMS and replace them with testing hook
methods. Allow to bypass them or call original MIDlet methods from
them. MIDlet.startUp method after instrumentation may look like:

public final void





Any comments will be appreciated.

Related Topics >>