How can I easily unit test Blackberry code?

Question

For my university class we are developing a multi-threaded Blackberry application which allows us to scan for other devices running our application with Bluetooth and then transfer files to each-other by TCP over the Wifi interface, implementing NAT traversal, all the while logging our GPS location. (It's a RIM sponsored Computer Networks class in case that wasn't obvious yet.)

I have grown fond of Test Driven Development and was going to employ it for developing my homework assignment. However, any Blackberry class which I extend or otherwise call during testing gives me a ClassFormatError due to illegal modifiers. I presume this error is caused because the jar with the Blackberry code must have been specially compiled for their proprietary JVM.

So far I've resorted to using the Proxy Pattern and implementing Mock Objects of the proxies. However, this is getting very tedious since I'm inheriting from many native Blackberry classes.

I would also like to avoid having to launch the Blackberry simulator if possible. It can take minutes just to boot it up and this is impractical and annoying for unit tests.

Is there am easy way to unit test my Blackberry code?

Answer 1

when I wanted to to unit-test some Windows Mobile code, I ran them on the simulator/emulator, and/or on the device itself.

This is not practical since I'm not going to launch a simulator which takes nearly a minute to boot after implementing every test/function.

I could boot it, load the software onto it, and run the test ... leave it running ... reload new application software onto it without rebooting, and rerun it. Maybe a Blackberry doesn't allow that?

Also, I could run a whole suite of tests in one shot (no need to reboot between each test/function). Maybe that's incompatible with TDD though, if your habit is:

1. Write a test case
2. Run it to ensure it fails
3. Write the implementation
4. Run it again, to ensure it succeeds this time
5. (repeat as above for the next function to be implemented)

It can happen though. Device drivers for example: tedious to debug, because the system may need to boot each time, because they hang the system if they're buggy, because the debugger isn't user-friendly ... environments like that are less interactve, so there's an greater emphasis on:

• Getting it right first time (so you don't have to debug)
• Implementing (and writing tests for, and subsequently testing) bigger (perhaps whole) chunks of functionality at once

Answer 2

Hi,

Is there any tool which gives code coverage information based on unit test covered using bbunit tool?

e.g. Clover, Eclemma etc tools refers junit test results and gives code coverage information.