在JMUnit中，任何使用这些断言调用之一的测试方法都必须抛出一个AssertionFailedException异常。框架使用该异常来标识失败的测试。现在，这个添加了适当测试方法的TemperatureConversionTest类看起来如下所示。

　　对于每一个标准的JUnit实现，JMUnit测试用例抽象类都提供了setup()和tearDown()方法，这两个方法都能够被重载并用于初始化，并在经由测试用例运行测试前后用来清除任何对象或资源。例如，在Java ME应用程序中，setup()可以用于在测试前打开一个记录存储，而tearDown()用于在测试后关闭记录存储。除了setup和tearDown方法外，还有一个fail()方法用于实现-无论assert语句显示什么内容，都允许一个测试方法返回一个测试失败。这个方法经常用于一个测试方法内的某些条件中，或用于作为未开发的单元测试的一个代理，从而作为一种方式来指示尚待完成的工作。

　　JMUnit中的每一个测试用例类都有一个相应的构造器。因此，派生自JMUnit的测试用例类的构造器必须调用超类构造器，并传入一个整数以指示在该测试用例中的测试个数，还要传入一个字符串来标识该测试用例。

　　这个整数指示测试的个数必须匹配测试用例中的实际测试的数目。确保你传入构造器的测试的个数匹配测试用例中的实际的测试的个数是相当重要的。当你分析该测试用例的test(int testNumber)方法，就会看到它们之间的关系。

　　测试用例中的这个test(int testNumber)方法负责"剔除"测试方法。因为Java ME缺乏映射能力，所以不能象在JUnit中一样，找到test方法并自动地执行之。因此，每一个测试方法必须被添加到该test方法中的一个switch语句中，并且基于一个测试号进行相应的调用。在我们的TemperatureConversionTest情况下，这个test方法看起来如下列代码所示：

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

　　这也正解释了为什么你必须向测试用例构造器提供一个测试号。在运行时刻，JMUnit框架创建一个测试用例类的实例。然后，框架在一个循环内调用该测试用例实例的每一个测试方法。通过这种方式，测试方法的switch语句中的每一个case语句(以及相应的每一个测试)都会被框架所调用。当把一个测试方法添加到测试用例中时，如果忘记更新测试用例类的构造器可能会导致部分测试用例不被激活。

　　因为你使用JMUnit编写测试方法，那么这可能会比基于JUnit更灵活一些：它允许执行测试方法。借助于测试方法的控制作用，你可以编写使用参数的测试-而这一点JUnit是不允许(由于反射机制)的。例如，针对TemperatureConverstionTest方法的一个测试方法可能看起来如下所示：

public void testcelsiusToFahrenheit(float c， float f) throws AssertionFailedException{
　System.out.println("celsiusToFahrenheit(float c)");
　float result = TemperatureConversion.celsiusToFahrenheit(c);
　assertEquals(f， result);
}