January 19, 2021
Hot Topics:

A Unit Testing Framework for the BlackBerry

  • By Jeff Langr
  • Send Email »
  • More Articles »

The software development scene currently offers an overwhelming menu of programming languages and frameworks. That's a good thing—it means that people are still trying to find better ways to help us solve problems in code. It also means that there's always something fun and new to learn. The downside is that I'm continually debating which technologies to dig into more deeply. Potentially, I have the following courses that could end up on my plate: Ruby and Ruby on Rails, Groovy and Grails, Erlang, D, Scala, Objective C, Java 2 Micro Edition (J2ME). That's only scratching the surface. And so far, that's all I've done with most of these technologies—simply scratch the surface.

Which to choose, then? I firmly believe that mobile devices will be the predominant platform in the not-so-distant future. I decided to start building a mobile-centric entertainment product. My intent is to initially develop a BlackBerry CDLC (Connected Limited Device Configuration) J2ME client that interacts with a Java server. Going into this choice was my thought that the familiarity of Java would help me deliver an initial release more rapidly. My thought is that I'll then port it to the iPhone (hence my interest in re-investigating Objective C).

My initial experience with J2ME and BlackBerry programming seemed like a step backward. Forays into coding for the BlackBerry revealed that a number of things I took for granted about modern Java programming are no longer available: things like regular expressions, reflection, and a robust collection class library. Instead, I'm coding my own regex replace methods, figuring out how to come up with non-reflective but elegant solutions, and using the ancient standbys of Vector and Hashtable. Never mind modern Java conveniences like the enhanced-for loop, generics, enums, and annotations.

Most significantly, the lack of reflection and/or annotations means that a unit testing framework seemingly requires a bit more work on the part of the interested programmer. Version 3 and earlier of the JUnit framework take advantage of reflection to locate all of the test methods within a given test class. That means that a programmer doesn't have to explicitly list the test methods, a tedious and risky exercise. Version 4 of JUnit uses annotations to similarly simplify tagging test methods. J2ME has neither of these techniques available.

I searched for existing unit testing tools. I found mention of three: J2MEUnit, Mobile JUnit, and BUnit. Mobile JUnit uses a compile-time code generation scheme to supplant reflection. Because BlackBerry uses a custom VM, I'm pretty sure Mobile JUnit won't work for my needs. J2MEUnit's architectural choices and its use of the midlet framework didn't appeal to me, based on what I read. And BUnit requires the developer to explicitly list test methods.

Perhaps one of these test tools has some hidden, positive surprises, or perhaps there's another, better solution that I've not yet found. Shamefuly, I'm not patient enough to find out. On the basis of my BlackBerry programming naivete, I instead decided to build my own framework. I justified my decision as a great way to learn more about developing for the BlackBerry.

Cutting to the chase, Listing 1 shows what a sample test looks like.

Listing 1: A sample BBTest test.

import java.util.*;
import com.langrsoft.bbtest.*;

public class SampleTest extends MicroTestGroup {
   private Vector list;

   public SampleTest() {
      add(new MicroTest("passingUseOfAssertEquals") {
         public void run() {
            Assert.assertEquals(0, list.size());

      add(new MicroTest("failingExceptionExpectation") {
         public void run() {
            try {
               list.add(new Object());
            catch (IllegalArgumentException expected) {

      add(new MicroTest("passing") {
         public void run() {

   public void setUp() {
      list = new Vector();

   public void tearDown() {

If you're not into anonymous inner classes, try one of the other tools! Using the BBTest framework, you create a test by deriving from the abstract class MicroTest and implementing the run method. You add each MicroTest subclass to a MicroTestGroup object. You name each test by passing a string to the constructor of MicroTest. MicroTestGroup objects can in turn hold other MicroTestGroup objects.

Other elements should look familiar. An Assert utility class provides a number of static assert methods, named after their JUnit analogs. MicroTestGroup also provides setUp and tearDown hooks for common initialization and clean-up, respectively.

I'll present interesting and core pieces of the framework in this article. You'll find a link to the complete BBTest framework at the end of this article. Note that it's a work in progress!

So, how does one build a test framework? Why, test-drive it, of course! In this case, I took an alternate approach: Instead of boot-strapping the framework with itself, I used JUnit 3.8, building the framework as a separate, normal Java project. The project contains a script that copies over the source to a BlackBerry JDE project.

First, the simple things. The Assert framework is straightforward. The most interesting aspect of test-driving the Assert framework is that AssertTest (see Listing 2) mixes both JUnit assertions and BBTest assertions. It's one of the few classes I've written where every class name is fully qualified! (Yes, there are less verbose solutions, but I wanted to avoid any possibility for confusion.)

Page 1 of 4

This article was originally published on July 24, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date