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

This article introduces the knowledge of "how to use JMUnit". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Use JMUnit

A) establish a JMUnit

After downloading JMUnit, make sure that the corresponding two JMUnit .jar files (JMUnit4CLDC10.jar and JMUnit4CLDC11.jar) are available in classpath. Note that this parameter applies to both your Java ME compiler and the runtime environment or IDE. Currently, the release of JMUnit is 1.0.2.

B) JMUnit test cases

JMUnit provides two versions of the framework (each within its own JAR); one for CLDC 1.0 applications and the other for CLDC 1.1 applications (where floating point prototypes are supported). According to a typical JUnit convention, the first step in creating an appropriate unit test using JMUnit is to create a test case. To create a test case in JMUnit, you must create a new test case class that derives from JMUnit's jmunit.framework.cldc10.TestCase or jmunit.framework.cldc11.TestCase. As the package name implies, one supports version 1.0 of CLDC and the other supports version 1.1 of CLDC. The only difference is that Java floating point prototypes are supported in the cldc11.TestCase implementation of the assertEquals () and assertNotEquals () methods (see below).

According to the JUnit custom, a test case class should contain the name of the class to be tested and end with "Test". Therefore, a simple CLDC version 1.1 JMUnit test case that tests the above temperature conversion class can be defined as follows:

Public class TemperatureConversionTest extends jmunit.framework.cldc11.TestCase {}

All test methods must be within a test case class. Also, by convention, test method names start with "test" and are then named after the methods in the class being tested. For example, a test case method for testing the fahrenheitToCelsius method should be testfahrenheitToCelsius. Each test method must "assert" the desired results. For developers who are not familiar with JUnit testing, an assertion is simply a statement that validates or proves what the programmer expects from the execution of a method. JMUnit supports the following assertions:

AssertTrue (expression)

AssertFalse (expression)

AssertSame (expected,actual)

AssertNotSame (expected,actual)

AssertEquals (expected,actual)

AssertNotEquals (expected,actual)

AssertNull (object)

AssertNotNull (object)

In JMUnit, any test method that uses one of these assertion calls must throw an AssertionFailedException exception. The framework uses this exception to identify failed tests. Now, the TemperatureConversionTest class with the appropriate test methods looks like this.

Import jmunit.framework.cldc11.*

Public class TemperatureConversionTest extends TestCase {

Public void testfahrenheitToCelsius () throws AssertionFailedException {

System.out.println ("fahrenheitToCelsius")

Float result = TemperatureConversion.fahrenheitToCelsius (66F)

AssertEquals (18.88889F result)

}

Public void testcelsiusToFahrenheit () throws AssertionFailedException {

System.out.println ("celsiusToFahrenheit")

Float result = TemperatureConversion.celsiusToFahrenheit (20F)

AssertEquals (68F, result)

}

Public void testisHotter () throws AssertionFailedException {

System.out.println ("isHotter")

AssertTrue (TemperatureConversion.isHotter (70Fjue 2F))

}

Public void testisCooler () throws AssertionFailedException {

System.out.println ("isCooler")

AssertTrue (TemperatureConversion.isCooler (10FMague 10F))

}

}

For every standard JUnit implementation, the JMUnit test case abstract class provides setup () and tearDown () methods, both of which can be overloaded and used for initialization, and used to clear any objects or resources before and after running the test through the test case. For example, in a Java ME application, setup () can be used to open a record store before testing, while tearDown () can be used to close the record store after testing. In addition to the setup and tearDown methods, there is a fail () method to implement-allowing a test method to return a test failure no matter what the assert statement shows. This method is often used in certain conditions within a test method, or as a proxy for undeveloped unit tests, as a way to indicate what remains to be done.

Each test case class in JMUnit has a corresponding constructor. Therefore, the constructor of the test case class derived from JMUnit must call the superclass constructor, passing in an integer to indicate the number of tests in the test case, and a string to identify the test case.

Public TemperatureConversionTest () {

Super (4, "TemperatureConversionTest")

}

This integer indicates that the number of tests must match the actual number of tests in the test case. It is important to make sure that the number of tests you pass into the constructor matches the actual number of tests in the test case. When you analyze the test (int testNumber) method of the test case, you will see the relationship between them.

The test (int testNumber) method in the test case is responsible for "culling" the test method. Because Java ME lacks mapping capabilities, you cannot find the test method and execute it automatically, as in JUnit. Therefore, each test method must be added to a switch statement in the test method and called based on a test number. In our TemperatureConversionTest case, the test method looks like the following code:

Public void test (int testNumber) throws Throwable {

Switch (testNumber) {

Case 0:testfahrenheitToCelsius (); break

Case 1:testcelsiusToFahrenheit (); break

Case 2:testisHotter (); break

Case 3:testisCooler (); break

Default: break

}

}

This also explains why you have to provide a test number to the test case constructor. At run time, the JMUnit framework creates an instance of the test case class. The framework then invokes each test method of the test case instance within a loop. In this way, every case statement (and each corresponding test) in the switch statement of the test method is called by the framework. When adding a test method to a test case, forgetting to update the constructor of the test case class may cause some test cases to not be activated.

That's all for "how to use JMUnit". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.