2. I find that I spend more time writing tests than application code but I’m happier with the application code that I produce; I spend less time coding and more time thinking (since I have to think about how to write testable code).

3. The MIDP apps that we write seem to have a lot of UI components and the application logic associated with actions for Forms, Lists, Canvases and even non-UI components may be common to several. When I find that I’m having to write a test that is similar to one that I’ve written for some other component I tend to extract a superclass, and then write tests for the super class so that I know that I don’t have to write boilerplate test code for the other classes that will extend the super class. I.e. I refactor more than I used. Naturally the unit tests give one a warm glow when they still pass after the refactoring.

4. When bugs are found outside of unit testing, I have been surprised at how easy it is to write short unit tests to replicate the bugs. TDD would appear to result in code whose testability goes beyond the tests written for the TDD.

I’m sure that none of the above is surprising to experienced TDD developers but as a Java ME developer who doesn’t come from a TDD background I found the test, code, test idiom great.

Finally, my feeling is that TDD in Java ME results in high quality code. In particular on my current project I have written 225 unit tests of which 221 were written as part of the TDD process. Outside of unit testing I found 3 bugs myself and 3 of the unit tests reflect those 3 bugs. A fourth bug was found during QA and the 225th unit test was written to replicate the bug.

Now for some caveats:
1. I’m not an authority on TDD.
2. Other people feel that writing testable Java ME code bloats it which may be serious if you’re building for old MIDP 1.0 devices. My feeling is that TDD allows for easier refactorings and that the refactorings can lead to significant code saving optimisations. But I have no metrics for either point of view.

SE Mobile Unit is worst solution because you only can run test by DebugOnDevice and not directly on any device

I am waiting to J2MEUnit 2.0, really it sound pretty good

FFFidalgo

This is a great article. I am new to your blog and i like what I see. I look forward to your future work.thanks for the tips. arcoxia if i made this at the beginning all the things were much easier….

One thing I find hard to accept in JMUnit APIs is that the test class hierarchy uses MIDlet as its base class (Assertion extends MIDlet).
First, it ties all tests to the MIDP platform and they are not reusable elsewhere even if the code under test is not MIDP-specific.
Second, it limits test automation possibilities. MIDP spec restricts MIDlet creation: only AMS is allowed to call “new MIDlet()”. This means that the only way to run JMUnit test is to use AMS to manually start the test; one cannot write a custom launcher without changing JMUnit APIs.
The other annoyance with the MIDlet-based hierarchy is that one cannot build JMUnit tests into the existing MIDP applications which are MIDlets themselves.

Hopefully, JMUnit 2.0 (the next version, which is supposed to be a merger of J2MEUnit and JMUnit) will fix the hierarchy and make it independent of the application model.

The only drawback of SE Mobile JUnit is that it is not open sourced so you can not customize or improve it for your own purpose.