Java Doc for TestCase.java in  » 6.0-JDK-Modules » j2me » com » sun » midp » i3test » Java Source Code / Java DocumentationJava Source Code and Java Documentation

The TestCase class and its assert() methods are loosely based on the JUnit TestCase class. JUnit uses reflection to find test methods. Since reflection isn't present in CLDC, we need to have a runTests() method that calls them explicitly.

JUnit, in contrast to other test frameworks, doesn't return a result from each test. Instead, each test simply makes assertions, and only assertions that fail are flagged. The i3 tests follow the JUnit approach. For this reason, there is no pass() method one might expect to see corresponding to the fail() method.

While it's not a requirement, it's conventional for the TestCase subclass to reside in the same package as the code under test. This will allow the tests access to package-private variables and methods.

Each of the different assert() calls has an optional message parameter. This message is emitted only when the assertion fails and should be written with this in mind.

For "negative tests" that require an exception to be thrown, a suggested style is to record the fact that the correct exception was thrown in a boolean variable. This variable can then be tested using one of the assert() calls. This is probably preferable to placing calls to fail() in the midst of the test method. See testThree() in the example below.

The framework will catch any Throwable thrown by the tests and will log a message and count the occurrence as an error. This allows tests to be written more simply, because they can rely on the framework to catch everything. In support of this, the runTests() method has been defined with a 'throws Throwable' clause.

A general rule is that tests should run independently of each other. That is, tests should not leave any side effects that other tests rely on or that could cause them to fail. Typically, tests should create fresh objects for testing instead of reusing objects from other tests. If a test has any external side effects, such as creating threads or opening files, the test should be coded with a 'finally' clause that attempts to clean up after itself. See testFour() in the example below.

Example:

 import com.sun.midp.i3test;
 package java.lang;
 public class SampleTest extends TestCase {
 void testOne() {
 int i = 1 + 1;
 assertEquals("integer addition failed", 2, i);
 }
 void testTwo() {
 Object x = new Object();
 assertNotNull("Object constructor returned null", x);
 }
 void testThree() {
 StringBuffer sb;
 boolean caught = false;
 try {
 sb = new StringBuffer(-1);
 } catch (NegativeArraySizeException e) {
 caught = true;
 }
 assertTrue("no exception thrown", caught);
 }
 void testFour() {
 Thread thr = new Thread(...).start();
 try {
 // ...
 } finally {
 thr.interrupt();
 }
 }
 public void runTests() {
 declare("testOne");
 testOne();
 declare("testTwo");
 testTwo();
 declare("testThree");
 testThree();
 declare("testFour");
 testFour();
 }
 }
 

A suggested organization is to have runTests() alternate calling declare() and an internal method that implements the test. One could write the declare() method as part of the internal test method, but consolidating all calls in runTests() makes it a little easier to ensure that each test has its own call to declare(). See the example in the class documentation.