Getting started with JavaME jUnit testing


Unit testing is a very powerful tool that should be included in every developer’s toolbox. Unfortunately, this has not always been the case, especially not among MIDlet developers. One reason is that JavaME projects usually are small (compared to Java SE projects), which implies that manual testing could be enough. However, as soon as you start developing production code you really should consider to automate your tests by developing your own test suite.

Some of you may have played around with JMUnit project. It is a nice framework that allows you to write tests that can be transferred to your phone or emulator and you will see the test result on the display. Alternatively, the tests can be executed by Ant. Still, there are some limitations that you cannot bypass:

  • Because of CLDC’s lack of reflection, you cannot benefit from the powers of jUnit 4.x.
  • You cannot create mock objects. This means that if a class has dependencies to other classes you will perform an integration test rather than a unit test.
  • The turn around time for test, debug and retest, is significantly larger compared to Java SE unit testing, especially if you are executing the test on the phone.

No offence to the JMUnit guys, they are restricted by the limitations of the CLDC VM and the fact that you need a target device (a phone or an emulator) to run the tests on. But maybe there is a workaround to solve these problems? With some tricks, it is possible to unit test your JavaME code in the same way as you would unit test your Java SE code. In other words, you can execute the tests on the PC side without deploying the tests to an emulator or a phone.


One part of the solution is to mock any platform dependencies. Previously, it was an awkward job to do, but the introduction of PowerMock allows us to mock the many static methods in MIDP and CLDC. The easiest way to get started with powermock is to download the In another post I have explained how PowerMock can be used to mock the RecordStore in MIDP.

Project configuration

If you are using Eclipse, you need two projects, one for your phone application and the other your test code. This is because different projects can have different java compiler settings.

  • Create a MIDlet project. This is your phone application. Make sure that the “Java Compiler” compliance level is “1.3”.
  • Create a Java project. This is the test project where you will write your tests. Make sure that the “Java Compiler” compliance level is set to “1.6” (or to whatever JDK version you have installed).
    • Add the midlet project you just created to “Required projects” in the “Java Build Path” setting.
    • Add the PowerMock jar files and their dependencies to “Libraries” in the “Java Build Path” setting.

In the MIDlet project, you write your application code and in the java test project you write your java jUnit tests. Normal package protection rules apply, so you should consider to reuse the package name from the class in the midlet project you would like to test when you are writing the test class in the java project.


Naturally, it is possible to automate the test by using build tools. Here is an example using of an Ant build.xml file:








Now your project configuration is setup and you can test your MIDlet code in the same way as you would test your Java SE code.

What’s next?

If you are a dedicated MIDlet developer you would probably like to add more build targets later on to preverify, obfuscate, sign, package and deploy your MIDlet.

You should also consider using a continuous integration server together with your version control system and configure it to run your test suite whenever the code has been changed. Depending on the server you choose, you may also find that it may be used to present result from static code analysis tools, code coverage, code metrics and so on.

Mattias Severson

Mattias is a senior software engineer specialized in backend architecture and development with experience of cloud based applications and scalable solutions. He is a clean code proponent who appreciates Agile methodologies and pragmatic Test Driven Development. Mattias has experience from many different environments, including everything between big international projects that last for years and solo, single day jobs. He is open-minded and curious about new technologies. Mattias believes in continuous improvement on a personal level as well as in the projects that he is working on. Additionally, Mattias is a frequent speaker at user groups, companies and conferences.

Leave a Reply