2010-01-12

J2ME Unit Testing

In the past I tried to get happy with unit testing of J2ME code.

I used JMUnit and J2MEUnit. JMUnit is a lot more straight forward while J2MEUnit is a high ceremony framework which requires a lot of boiler plate code just to be as much like JUnit as possible.

But in the end both suck. All J2ME testing frameworks will suck.

Why? Because unit testing should be easy and fun but compile, preverify, deploy to the emulator or the device, doing some manual steps just to see that something is broken isn't fun and it's also not easy.

There is a lot of stuff you have to try on the phone but that has nothing to do with unit testing but it's tinkering around implementation issues. You will have to do that anyway and I guess both frameworks are of little help here.

So what is the answer to J2ME unit testing?

In my opinion the best approach is to do unit testing on the PC inside the IDE. Using JUnit 4 and Java SE.

I'm currently giving this solution a try. I have a separate project with a dependency on the J2ME project.

For all those J2ME classes you need stubs. I haven't found usable code on the net so I write them myself. (I don't have a lot of them yet)

The good thing is you can really take control over everything with your own implementation of the J2ME classes. Your own bluetooth connection, file connection ... you name it. It's a lot of work but you can do almost anything. Once you have your mocks and stubs in place you will see how much better this approach is.

But the best about this is that the tests run fast, you can exhaust all the cool stuff from your IDE from good debugging support to integrated JUnit support, you can use mocking frameworks like Mockito, EasyMock etc., you can use a modern framework  (JUnit 4)  and you could even use coverage analysis integrated into your IDE (but I haven't tried it yet).

It should also be easy to integrate this into the build and run the tests on the CI server. (This is a nightmare with the "pure" J2ME solution.)


This idea is inspired by an experimental approach to unit testing on Android which is something I will try on one of my next Android projects.

2 comments:

  1. Hai...! i am obulreddy.
    what is the difference between J2MEUnit and Jinjcetor?

    ReplyDelete
  2. J2MEUnit is just a unit testing framework like many others. In fact it's just a plain simple unit test runner without any bells and whistles.

    JInjector is very different. It's capable of doing byte code magic to your classes. By doing that you can use it for e.g. test coverage analysis or doing system tests.

    It can create wrappers for all the LCDUI classes and this way you can test you application at the UI level. e.g. you can have tests that fill in some data into a form and simulate choosing an command. Then you can verify that your code did what it's supposed to do by checking if the next screen displays the right stuff.

    I once tried it and had a very hard time setting JInjector up and to be honest I don't think it's worth the hassle. These kind of tests break too easily and are very hard to maintain.

    Unless the tool you use for these tests isn't really easy to use it might be more effective to do manual acceptance / system testing.

    But nevertheless you should certainly do automated unit testing.

    By using the approach outlined above you can do test driven development for J2ME which wouldn't be reasonable to do with on device unit testing because the turn around times are way too long.

    ReplyDelete