Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I just wanted to verify what I have found by my experience and googling. First, a little background.
1) I can run my unittest suites from both test runners
2) I can't run successfully on any test that tries to instantiate an object that extends MIDlet.
a) In the textui.TestRunner fails on a Configuration.getProperty0 error
b) In the midlet.TestRunner it throws a SecurityException
So, my assumption is that J2MEUnit works great when not trying to instantiate a MIDlet so if we want to unittest our J2ME code we should put the code we want to test external to the MIDlet and have the MIDlet call out to the other object.
Is that assumption correct? Is there any way to successfully instantiate a MIDlet in a J2MEUnit test so that I can call the objects methods (i.e. unittest them)?
J2MEUnit comes with a MIDlet test runner that you can use to run tests. Look at the examples and test cases that come with it. These are working test cases. If you have problems it would help if you mentioned the WTK version you are using.
I haven't worked on J2ME projects for some time so I cannot say if there are problems with the recent WTK versions. If you find such problems feel free to contribute to J2MEUnit by telling us about them.
There's also a text UI test runner which is from the old J2MEUnit suite created by Role Model Software. I'm not sure if this will work with current J2ME toolkits.
I understand the test runners and can run both of the test runners with all of the examples. However, all of the tests do not actually instantiate an object that extends MIDlet. When I test any other class all my tests are fine, but when I try to run a test on a class that extends MIDlet I get the errors that I listed in my first mail.
>all of the tests do not actually instantiate an object that
Of course not. These are UNIT tests that test single functional aspects of application code. J2MEUnit is not intended to perform integration tests on parts of or even full applications. Please visit www.junit.org for more information on unit tests.
I don't think I'm trying to functest; with our testing policies we try to get 100% unit test code coverage (as much as possible) on all methods (whether they are in a MIDlet or not). Shouldn't I still be able to instantiate a class even if it is a class that extends MIDlet to unittest a method on that class? In order to get around this, I've basically moved all of the functionality out of the MIDlet class and into other classes. It works and allows me to unittest pretty much everything except the entrance into and exit out of the app.
Thanks for your replies.