Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about how to understand the concept of J2ME unit testing. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

J2ME Unit is a unit testing framework designed and developed by KentBeck and ErichGamma, which imitates JUnit on the J2ME platform, the size of 17KB. Its application provides basic support for writing guaranteed J2ME program code.

J2ME Unit Test (JUnit)

Introduction to J2ME Unit:

Using JUnit and other unit testing frameworks for unit testing is no stranger to Java programmers. Using these very effective tools, the quality of the code can be effectively monitored and maintained. However, everything seems a little different on the J2ME platform. Because the J2ME environment does not provide Reflection API, many reflection-based features are not available, such as the ability to automatically create and run testsuite in JUnit. Most J2ME programmers cannot use JUNIT for unit testing on the J2ME platform, but everyone knows how fragile a program without unit testing is!

J2ME Unit is a unit testing framework designed and developed by KentBeck and ErichGamma, which imitates JUnit on the J2ME platform, the size of 17KB. Its application provides basic support for writing guaranteed J2ME program code. J2MEUnit introduces some new mechanisms to solve the dependence of the original JUnit on reflection. J2MEUnit may not be as convenient as JUnit in use, but at this stage we can only use it, enthusiastically looking forward to the reflection support of the J2ME environment. The current version of J2MEUnit is 1.1.1. Like JUnit, it is open source. You can find his download on sf.net. Compared with the frequent upgrade of JUnit, J2MEUnit has not been upgraded for some time, on the one hand, the effort is small, on the other hand, considering the particularity of the J2ME environment, it is necessary to ensure that the LIB tested is small enough.

Build a test platform:

We use Eclipse with EclipseME as an example to illustrate how to use J2MEUnit.

First go to sf to download the * version of J2MEUnit: http://J2MEUnit.sourceforge.net, and extract it to your favorite directory.

Create a new MidletSuite and select Project. > properties... > JavaBuildPath... > Libraries... > AddExternalJARs... Select the J2MEUnit.jar in the path you need to download.

So it can be used.

Write test classes:

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

Write TestCase classes

The class that writes the test inherits J2MEUnit.framework.TestCase. As in JUnit, you can override the setUp () and tearDown () methods. Although there is no reflection mechanism here, it is recommended that you start the test method with test. In this way, once J2ME has a reflection mechanism, you can quickly migrate it. Another thing to note is that you need to provide a constructor for the subclass (assuming your class is called TestOne):

PublicTestOne (StringsTestName,TestMethodrTestMethod) {super (sTestName,rTestMethod);}

Explain later why?

Next, write two test methods, which are familiar:

PublicvoidtestOne () {System.out.println ("TestOne.testOne ()"); assertTrue ("Shouldbetrue", false);} publicvoidtestTwo () {System.out.println ("TestOne.testTwo ()"); thrownewRuntimeException ("Exception");}

Because of the lack of reflection mechanism, you need to write suite methods manually and call the test methods you write one by one, which is more or less tedious. There is no way, this is the key to understanding the J2MEUnit framework, we even put up with writeoncedebuganywhere, what difficulties can not be overcome?

The suite method requires us to return a TestSuite object, so first create a new TestSuite object and call the addTest method to add a Test object for him. Test is an interface, which is implemented by TestSuite and TestCase, so you can add both a test unit and a test suite.

According to the design idea of J2MEUnit, a TestCase can only bind one TestMethod object when it is running. TestMethod is a standard callback interface with only one callback run (TestCasetc) method. The task of this run method is to call a, note, a test method, so if there is a problem with this method, it can be well captured and returned to the user. TestMethod provides a set of set methods for bundling a TestMethod object, but we don't actually use it because it's too inefficient. In order to bind TestMethod objects more quickly, we use constructors and anonymous classes to bind instances of the TestMethod class. This anonymous class is easy to write, just transform the incoming TestCasetc up to your TestCase subclass, and then call the relevant methods. We have to also provide a String as the name to our constructor

Take a look at the following example, hoping to help you understand that the above paragraph is always a bit of a mouthful. If you understand the phrase "a TestCase can only bind one TestMethod object while it is running," then you understand J2MEUnit's so-called new mechanism. Never call multiple test methods in succession in a TestMethod, so that if something goes wrong with a method, the entire method will end and subsequent tests will not be executed. Must be honest, seriously write suite (), it seems to return to the era of scissors and paste.

PublicTestsuite () {TestSuiteaSuite=newTestSuite (); aSuite.addTest (newTestOne ("testOne", newTestMethod () {publicvoidrun (TestCasetc) {((TestOne) tc). TestOne ();})); aSuite.addTest (newTestOne ("testTwo", newTestMethod () {publicvoidrun (TestCasetc) {((TestOne) tc). TestTwo ();}})); returnaSuite;}

Write test suites

Next, write a test suite. in fact, you may already understand that the test suite is just a special TestCase. According to convention, such a class is generally called TestAll. You only need to add the suite from the previously added TestCase to TestAll's suite.

PublicclassTestAllextendsTestCase {publicTestsuite () {TestSuitesuite=newTestSuite (); suite.addTest (newTestOne (). Suite ()); suite.addTest (newTestTwo (). Suite ()); returnsuite;}}

Debug:

There are two ways to run our test.

Use textui

Use textui, this everyone is familiar with, do not make the key introduction. It is customary to add a main method to the TestAll method:

Publicstaticvoidmain (String [] args) {String [] runnerArgs=newString [] {"J2MEUnit.examples.TestAll"}; J2MEUnit.textui.TestRunner.main (runnerArgs);}

To pass in a String array for TestRunner.main, it lists the full paths of all the TestCase to be tested, because we have written TestAll, so just pass in him.

Use midletui

This is the fascinating part of this framework, it is with him that we can do UnitTest on the real machine, cool, how much testing costs will be saved. So all the previous work of writing suite will be accepted!

Inherits J2MEUnit.midletui.TestRunner, which is a midlet parent class. Call the following method in startApp:

ProtectedvoidstartApp () {start (newString [] {"J2MEUnit.examples.TestAll"});}

Or, more flexibly, you can write a J2MEUnitTestClasses attribute in the jad file to write several TestCase you want to test, so that you can also test without changing the main class.

The simulation results are as follows:

Screen.width-460) this.width=screen.width-460 ">

On my MIDP1.0, run this example on a real machine to get the same result, using 401ms. If you are using j2me development projects, it is recommended to introduce unit testing into your work, just as we have seen the impact of unit testing on other java platforms, it is also a great opportunity for embedded development.

The above is the editor for you to share how to understand the concept of J2ME unit testing, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.