Comprehensive Analysis of the j2_unit testing philosophy (1)

The j2munit is a Unit test framework designed and developed by KentBeck and ErichGamma to imitate JUnit on the j2mplatform. The Unit size is 17 kb. Its application provides basic support for compiling well-secured Java program code.

J2-unit testing (JUnit)

Introduction to j2ecunit:

Using unit testing frameworks such as JUnit for unit testing is no stranger to Java Programmers. Using these very effective tools, the quality of code can be effectively monitored and maintained. However, it seems that everything is slightly different on the j2's platform. Because the j2-based environment does not provide Reflection) API, many Reflection-based functions cannot be used, such as automatically creating and running the testsuite function in JUnit. The majority of j2s programmers cannot use JUNIT for unit testing on the j2s platform, but everyone knows how fragile a program without unit testing is!

The j2munit is a Unit test framework designed and developed by KentBeck and ErichGamma to imitate JUnit on the j2mplatform. The Unit size is 17 kb. Its application provides basic support for compiling well-secured Java program code. J2MEUnit introduces some new mechanisms to solve the reflection dependency of the original JUnit. J2MEUnit is obviously not as convenient as JUnit, but we can only use it at this stage. We are eager to support reflection in the J2MEUnit environment. The current J2MEUnit version is 1.1.1. Like JUnit, it is also open-source. You can find its download on sf.net. Compared with JUnit, J2MEUnit has not been upgraded for a while. On the one hand, the investment is relatively small. On the other hand, it may be because of the special nature of the J2MEUnit environment. Ensure that the LIB for testing is small enough.

Build a Test Platform:

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

First download the latest J2MEUnit version: http://J2MEUnit.sourceforge.net from sf and decompress it to your frequently used directory.

Create a MidletSuite and select Project...> Properties...> JavaBuildPath...> Libraries...> AddExternalJARs... Select J2MEUnit. jar from the download path.
　
In this way, you can use it.

Compile the test class:

Let's write a TestCase to learn how to use this tool.

Compile the TestCase class

The classes to be tested must inherit J2MEUnit. framework. TestCase. As in JUnit, You can override the setUp () and tearDown () methods. Although there is no reflection mechanism, we recommend that you start the test method with test. This way, but with the reflection mechanism, you can also port it quickly. Note that you need to provide a constructor for the subclass. Assume that your class is called TestOne ):

 
 

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

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");  
  
  
} 
 
 

There is a lack of reflection mechanisms. You need to manually write the suite method and call the test method you have compiled one by one. This step is more or less boring. No way. This is the key to understanding the J2MEUnit framework. The producer can endure the writeoncedebuganywhere operation. What difficulties cannot be overcome?

The suite method requires that we return a TestSuite object. Therefore, first create a new TestSuite object and call the addTest method to add the Test object to it. Test is an interface that is implemented by TestSuite and TestCase. Therefore, you can add both a Test unit and a Test suite.

According to the J2MEUnit design idea, a TestCase can only bind one TestMethod object during runtime. TestMethod is a standard callback interface that only contains one callback run (TestCasetc) method. The task of this run method is to call one. Note that it is a test method. Once a problem occurs in this method, it can be captured and returned to the user. TestMethod provides a set method to bind a TestMethod object, but we don't actually use it, because the efficiency is too low, in order to more quickly bind the TestMethod object, we need to use constructors and anonymous classes to bind TestMethod class instances. This anonymous class is well written. You only need to transform the passed TestCasetc to your TestCase subclass, and then call the relevant methods. We have to provide a String as the name for our constructor at the same time.

Let's take a look at the example below, hoping to help you understand what the above section always feels like a bit of mouth-breaking. If you understand the phrase "A TestCase can only bind one TestMethod object at runtime", you will understand the so-called New Mechanism of J2MEUnit. Do not call multiple test Methods consecutively in one TestMethod. In this way, once a method has a problem, the entire method will end and subsequent tests will not be executed. Must be honest, and really write the suite), it seems that back 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;  
  
  
}