Unit Testing using J2meunit

First, introduce

Unit testing using a unit test framework such as JUnit is no stranger to Java programmers, making the quality of the code effectively monitored and maintained by leveraging these very effective tools. Yet it seems that everything is slightly different on the J2ME platform. Because the J2ME environment does not provide a reflection (Reflection) API, many reflection-based features are not available, such as the ability to automatically create and run the test suite in JUnit. The vast majority of J2ME programmers cannot use JUnit for unit testing on the J2ME platform, but everyone knows how fragile a program without unit tests is.

J2meunit is a unit test framework designed by Kent Beck and Erich Gamma to mimic junit on the J2ME platform, size 17KB. Its application provides basic support for writing guaranteed J2ME program code. J2meunit introduced a number of new mechanisms to address the original JUnit dependency on reflection. May be in use j2meunit obviously without junit convenience, but at this stage we can only use it, enthusiastic look forward to the J2ME environment for reflection support. The version of the existing J2meunit is 1.1.1. Like JUnit, it is open source. You can find his download on the sf.net. Compared to junit often upgraded, j2meunit for a period of time did not upgrade, on the one hand, the strength of the small, but also may be taken into account the specificity of the J2ME environment, to ensure that the test lib enough small. second, build the development environment

We illustrate how to use J2meunit with Eclipse with Eclipseme as an example.

First go to SF to download the latest version of J2meunit: Http://j2meunit.sourceforge.net, and unzip it into your common directory.

Create a new MIDlet Suite, select Project...>properties...>java build Path...>libraries...>add External JARs ... Select the J2meunit.jar in the path you want to download.

So you can use it. third, the writing test class

Let's write a testcase to learn how to use this set of tools. writing TestCase class

The class that writes the test inherits J2meunit.framework.TestCase. As in JUnit, you can override the setUp () and Teardown () method, although there is no reflection mechanism, but it is recommended that you put the test method at the beginning. Such a J2ME has a reflex mechanism and you can also quickly migrate. It is also important to note that you need to provide a constructor for the subclass (assuming your class is called Testone):

Public Testone (String stestname, TestMethod Rtestmethod)

{

Super (Stestname, Rtestmethod);

}

Explain why this is a while later.

Next, write two test methods that are familiar:

public void Testone ()

{

System.out.println ("Testone.testone ()");

Asserttrue ("Should be True", false);

}

public void Testtwo ()

{

System.out.println ("Testone.testtwo ()");

throw new RuntimeException ("Exception");

}

It is the lack of reflection that you need to manually write the suite method and call the test methods you write, which is somewhat boring. No way, this is the key to understanding the J2meunit framework, I even write once debug anywhere have endured, what difficulties can not overcome it.

The suite method requires us to return a TestSuite object, so we first create a new TestSuite object and invoke the Addtest method to add the Test object to him. Test is an interface that TestSuite and testcase all implement, so you can add test cells and add a test suite.

According to J2meunit's design idea, a testcase can only bundle a TestMethod object at run time. TestMethod is a standard callback interface that contains only one callback run (TestCase tc) method. The task of this run method is to call a, note, a test method, so once this method is problematic, it can be well captured and returned to the user. TestMethod provides a set of set methods to bundle a TestMethod object, but we do not use it because it is too inefficient, and in order to quickly bundle TestMethod objects, we use constructors and anonymous classes to bundle instances of the TestMethod class. This anonymous class is well written, as long as the incoming TestCase TC is transformed up into your testcase subclass, and then the associated method is invoked. We have to also provide a string as a name to our constructor (remember.) The constructor that we added, here, understand her usefulness.

Take a look at the following example, hoping to help you understand the above paragraph always feel a bit clumsy words. If you understand the phrase "a testcase can only bundle a TestMethod object" when it is running, then you understand the j2meunit so-called new mechanism. Never call multiple test methods in a testmethod, so that once a method goes wrong, the entire method ends and subsequent tests are not executed. Must be honest person, seriously write a suite (), seems to be back to the era of scissors and paste ... [-_-"]

Public Test Suite ()

{

TestSuite asuite = new TestSuite ();

Asuite.addtest (New Testone ("Testone", New TestMethod ()

{public void Run (TestCase tc) {(testone) TC). Testone ();}));

Asuite.addtest (New Testone ("Testtwo", New TestMethod ()

{public void Run (TestCase tc) {(testone) TC). Testtwo ();}));

return asuite;

Write test suite

Next, write a test suite, as you may already understand, the test suite is just a special testcase, according to the Convention, the General class is called Testall, you just have to add the previously added testcase to the Testall suite.

public class Testall extends TestCase

{

Public Test Suite ()

{

TestSuite Suite = new TestSuite ();

Suite.addtest (New Testone (). Suite ());

Suite.addtest (New Testtwo (). Suite ());

return suite;

}

Iv. Debugging and running

There are two ways to run our tests. using Textui

The use of Textui, this everyone is familiar with, do not focus on the introduction. It is generally customary to add a main method to the Testall method:

public static void Main (string[] args)

{

string[] Runnerargs = new string[] {"J2meunit.examples.TestAll"};

J2meunit.textui.TestRunner.main (Runnerargs);

}

To pass in a string array for Testrunner.main, which lists all the full paths of the testcase to be tested, because we wrote the Testall, so just pass it on to him.

using Midletui

This is where the framework is fascinating, and it is with him that we can do unit test on the real machine, cool, how much the test cost will be saved. So all the previous work of writing a suite was recognized.

Inherits J2meunit.midletui.TestRunner, which is a MIDlet parent class. The following methods are called in Startapp:

protected void startApp ()

{

Start (new string[] {"J2meunit.examples.TestAll"});

}

Or, more flexible, you can write a j2meunittestclasses attribute in the Jad file, write a few testcase you want to test, and you can test without changing the main class.

The following are the results of the simulations:

It's still very intuitive, right.

In my MIDP1.0, the real machine runs This example to get the same result, spents 401ms. If you are using a J2ME development project, it is recommended that you introduce unit tests into your work, as we see the impact of unit testing on other Java platforms, which is also useful for embedded development.

BTW, the above test examples can be found in the J2meunit full release, enjoy it. Finally, Favoyang welcome you to j2medev.com Exchange, publish your technical articles, participate in the discussion forum.