We wanted to set up an automated testing environment for the Blackberry in which we could test against multiple versions of a real BES. We have a pretty solid framework for automated testing of OfficeWriter, and since it proved itself to be very beneficial, we decided to try to do the same for our BlackBerry product. We already have a framework in place which runs automated tests on the simulator using the MDS simulator. We even extended this framework to run against an actual SharePoint server, although that’s a topic for another blog post. So, if precedence counts for anything, setting up an automated test environment for BlackBerry should have been a snap, right? Wrong. Here I wish to describe the path we walked down as we tried to set up a test environment that would run automatically against a real BES.
In order for a simulator to run against a real BES, it needs to connect to Desktop Manager, so we have set up two (Windows 7 64bit) virtual machines, each with a simulator and a Desktop Manager set up with a user provisioned through BES – one for BES 4 and one for BES 5. In order to automatically access and control these machines we chose to use PsExec from our Ant script using the exec tag and passing in the needed arguments. So, for example the followings, as part of an Ant target, will restart MyRemoteMachine using PsExec: Continue reading Setting An Automated BlackBerry Test Environment Against A Real BES: A Story Of Failure
In some peculiar cases there will be an error thrown somewhere in the Blackberry modules that were invoked from your coed, but the error will never return to you, even with a try-catch block set. The stack trace of the error will be printed to the console, your process will be terminated and an error message will pop up on the device/simulator screen with: Uncaught exception: and the exception name.
An example for this is the Controlled Access Exception. When trying to open a file that is access controlled, even a specific catch for this error it will not matter, the process will be killed and the error window for uncaught exception will pop up. The best practice is of course to check for access control before reaching for the file, but it still doesn’t make sense to have it swallow the error and kill the process instead of bubbling it up. Also, for the access control it’s pretty straight forward, but now I have encountered it again, with a java.lang.Error exception and the process gets killed… java.lang.Error is slightly less informative than ControlledAccess Continue reading Blackberry Swallowed My Error
I encountered an interesting (and frustrating issue) with the BlackBerry simulator in Eclipse. I got an error upon starting the simulator that the *.debug file was not found with some options to search and browse for it. Looking around my system showed that indeed – no *.debug files exist. I’ve tried many things, erasing all my Simulator Files, cleaning the build, re-building and so on, to nothing helped. Eventually I ran into this forum threadin the blackberry forums discussing this specific problem. It turns out that sometime, even though there are errors in the build – no errors will be shown, making you believe the build was successful. However, this is not the case. There should be an *.err file (were the *.debug file should have been) describing a compilation error in code.
Seeing that this came from the same error mentioned in the thread – _X is not Persistable: base Class does not implement net.rim.vm.Persistable_ , it might be that this specific error has a problem displaying in Eclipse.