Unit Testing using J2meunit

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 later why is this?

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;

}
Writing test Suites

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. Commissioning and operation

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.